Configure SPF, DKIM, DMARC to Prevent Email Spoofing

Email spoofing and phishing remain among the most common cybersecurity threats. Malicious actors can send forged emails using your domain name, damaging your business reputation and deceiving your customers. This guide walks you through configuring SPF, DKIM, and DMARC records step by step to close these vulnerabilities and fully protect your domain.

SPF, DKIM, DMARC Overview — Who Does What

All three standards are email authentication mechanisms that live in your domain's DNS. They do not replace one another — they layer together. SPF verifies who is allowed to send, DKIM verifies that the message content was not tampered with, and DMARC is the policy that decides what to do when the first two fail. The table below summarises each one's role, record type, and an example value so you have the big picture before configuring them step by step in your domain's DNS.

The key takeaway is that all three are TXT records configured entirely in your domain's DNS Management. If you register your domain and manage DNS at AsiaGB through DirectAdmin, you can add and edit every one of these records yourself in one place, with no dependency on an external provider.

What is SPF and How Does It Work?

SPF (Sender Policy Framework) is a DNS TXT record that specifies which IP addresses or mail servers are authorized to send email on behalf of your domain. When a receiving server gets an email, it checks the sender's IP against your SPF record. If the IP is not listed, the email is flagged as suspicious or rejected.

SPF Record Structure

A basic SPF record example:

v=spf1 include:thirdpartydomain.com ip4:203.0.113.10 ~all

• v=spf1 — Declares SPF version 1
• include: — Includes the SPF policy of a third-party mail provider (e.g., Google Workspace, Mailchimp)
• ip4: — Directly authorizes a specific IP address
• ~all — SoftFail: emails from unlisted IPs are flagged but delivered (recommended for initial setup)
• -all — HardFail: emails from unlisted IPs are rejected outright (use after thorough testing)

Adding SPF on DirectAdmin

1. Log in to DirectAdmin → DNS Management
2. Set Type to TXT
3. Set Name to @ (root domain)
4. Set Value to v=spf1 include:YOUR-MAILPROVIDER.com ~all
5. Save and wait 1–4 hours for DNS propagation

Configure an SPF Record Step by Step (DNS TXT)

Let's walk through a real SPF setup in your domain's DNS Management. Suppose you send mail through the AsiaGB mail server and also use one external newsletter service. The goal is to combine every legitimate sending source into a single SPF record.

1. Open DirectAdmin → DNS Management for the domain.
2. Check first whether a TXT record starting with v=spf1 already exists — if so, edit the existing one rather than creating a second.
3. Create/edit a TXT record: Name = @, Type = TXT.
4. Enter the Value, listing every real sending source such as the primary mail server plus external providers:

@   TXT   "v=spf1 a mx include:_spf.asiagb-mail.com include:servers.mailprovider.net ~all"

• a — Authorises the domain's A record IP (e.g., a web server that sends form mail).
• mx — Authorises the MX server IPs (the servers handling the domain's mail).
• include: — Pulls in another provider's SPF policy (you can chain several).
• ~all — Always close with SoftFail (start with ~all, switch to -all once confident).

After saving, wait roughly 1–4 hours for DNS propagation, then verify with dig TXT yourdomain.com or an online tool that the published value matches what you set. Mind the 10 DNS lookup limit: SPF caps the total number of include: / a / mx mechanisms that trigger a DNS lookup at 10. Exceeding it produces a PermError and breaks SPF entirely — if you use many providers, remove unnecessary includes.

What is DKIM and How Does It Work?

DKIM (DomainKeys Identified Mail) is a digital signature system for email. The sending mail server adds a cryptographic signature to each email's header. The receiving server then verifies this signature against the public key published in your DNS. If the signature matches, the email is confirmed as unaltered in transit.

DKIM Record Structure

DKIM records are added at a subdomain in the format selector._domainkey.yourdomain.com:

mail._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..."

• selector — A label defined by your mail server (e.g., "mail", "google", "s1")
• k=rsa — Uses RSA encryption
• p= — The public key obtained from your mail provider

Getting Your DKIM Key

If you host email with AsiaGB, DKIM keys are generated automatically and available in DirectAdmin → Email → DomainKeys. For third-party providers such as Google Workspace or Microsoft 365, retrieve the DKIM key from the respective admin console and add it to your domain's DNS.

Configure DKIM (Enable in DirectAdmin + TXT)

DKIM differs from SPF in that it requires a key pair (the private key stays on the mail server; the public key is published in DNS). On AsiaGB, DirectAdmin generates the keys for you automatically — you simply enable it and publish the public key in DNS.

1. Open DirectAdmin → Email Manager → DKIM Keys (in some themes under E-Mail Accounts → DomainKeys).
2. Enable DKIM for the domain — the system creates a private key and shows the public key as a TXT record plus a selector (often x or default).
3. Copy the TXT value provided. If DNS is managed on the same server, DirectAdmin usually adds the record automatically — confirm in DNS Management that this record exists:

x._domainkey   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

If your domain's DNS points to another provider (e.g., Cloudflare), take the public key from DirectAdmin and create the TXT record manually there, using selector._domainkey as the Name as defined by the system. For Google Workspace or Microsoft 365, retrieve the public key from that service's admin console instead, since the private key lives on the provider's mail servers.

What is DMARC and How Does It Work?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a policy that tells receiving servers what to do with emails that fail SPF or DKIM checks. It also generates reports so you can monitor who is attempting to spoof your domain.

DMARC Record Structure

Add a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100

• p=none — Monitor only, no action taken on failing emails (use during initial deployment)
• p=quarantine — Send failing emails to spam/junk folder
• p=reject — Completely reject failing emails (most secure)
• rua= — Send aggregate reports to this email address (daily)
• pct= — Percentage of emails the policy applies to (100 = all)

Configure a DMARC Policy (none→quarantine→reject, rua report)

DMARC is the top layer that tells receiving servers what to do with mail that fails SPF/DKIM. The core principle is to ramp up the policy gradually from none to quarantine and finally reject, so legitimate mail is never broken along the way. Create a TXT record at _dmarc like this:

1. Step 1 — Monitor (p=none): Start in monitor-only mode. It does not affect delivery but opens reporting:

   _dmarc   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r; pct=100"

2. Step 2 — Quarantine (p=quarantine): Once reports confirm SPF/DKIM cover all real sources, switch to quarantine so failing mail lands in spam:

   _dmarc   TXT   "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"

3. Step 3 — Reject (p=reject): The strictest level, rejecting spoofed mail outright — use only once everything has been stable for several weeks:

   _dmarc   TXT   "v=DMARC1; p=reject; rua=mailto:[email protected]"

Common tags you will use:

• rua= — Address for aggregate reports (daily XML summaries of who sent as your domain and how many passed/failed).
• ruf= — Address for forensic reports (per-message detail; some receivers withhold these for privacy).
• fo=1 — Send a forensic report when either SPF or DKIM fails.
• adkim / aspf — Alignment mode: r = relaxed (recommended), s = strict (exact match required).
• pct= — Percentage of mail the policy applies to; ramp gradually, e.g., pct=25 before moving to 100.

rua reports arrive as compressed XML files that are hard to read raw. A DMARC report-viewing service that turns them into charts makes it clear which sources still fail, so you can add them to SPF/DKIM before tightening the policy.

Recommended Implementation Order

Follow this sequence to minimize the risk of blocking legitimate emails during setup:

1. Add SPF Record — Start with ~all (SoftFail)
2. Add DKIM Record — Get the key from your mail provider and add it to DNS
3. Test SPF + DKIM — Send a test email and verify both pass in the headers
4. Add DMARC with p=none — Collect reports for 1–2 weeks
5. Review reports and adjust SPF — Ensure all sending servers are included
6. Switch to p=quarantine — Once confident your SPF is complete
7. Switch to p=reject — Final step when everything is stable

Tools to Test SPF, DKIM, and DMARC

Several free online tools help you verify your configuration instantly:

• MXToolbox (mxtoolbox.com) — Check SPF, DKIM, DMARC, and MX records in one place
• mail-tester.com — Send a test email and receive a score with improvement recommendations
• Google Admin Toolbox — Best for Google Workspace users
• DMARC Analyzer — Detailed DMARC report analysis

Frequently Asked Questions (FAQ)

Do I need all three of SPF, DKIM, and DMARC?

Yes, ideally all three, because they complement each other. With SPF alone, attackers can still spoof the display name or use forwarding to slip through. DKIM closes the door on content tampering, while DMARC enforces policy and provides reporting. Without DMARC you have no visibility into who is attempting to spoof your domain. Having all three improves both security and deliverability at the same time.

How long after setup before it takes effect?

It comes down to DNS propagation. TXT records typically spread within 1–4 hours, but it also depends on the existing record's TTL. If the TTL is high (e.g., 86400 seconds = 1 day) you may have to wait until the old cache expires. We recommend lowering the TTL (e.g., to 3600) before editing during testing, then verifying with dig TXT yourdomain.com that the new value is live.

I already have SPF and DKIM — do I still need DMARC?

Yes. SPF and DKIM only perform checks; they do not tell the receiving server what to do when a check fails. DMARC is the layer that sets the policy (none/quarantine/reject) and sends rua reports back to you showing which IPs are sending spoofed mail. Without DMARC, spoofed mail that fails SPF/DKIM may still reach the recipient's inbox.

Can I set p=reject from the start?

Not recommended. Jumping straight to p=reject risks rejecting legitimate mail entirely — for example from an invoicing system or a newsletter you forgot to add to SPF. Start with p=none to collect rua reports for at least 1–2 weeks, identify any sources that still fail and fix them, then move up to quarantine and reject in order.