Skip to content

Singapore Bureau

Best Asian BusinessesAPAC business recognition

Explainer · March 11, 2026

Email authentication explained: SPF, DKIM and DMARC

By the editorial panel · Best Asian Businesses

Email authentication explained in one line: it is a set of three DNS records that let a receiving mail server check that a message really came from the domain it claims. The records are called SPF, DKIM and DMARC. Each does one job, and together they make it hard for a stranger to send mail in your name.

What each record does

SPF is a list of the servers allowed to send mail for your domain. You publish it as a DNS TXT record. The receiving server checks the sending server's address against that list. SPF is defined in RFC 7208.

DKIM adds a digital signature to each message. Your mail system signs the message with a private key. You publish the matching public key in DNS, under a name that includes a "selector". The receiver uses that key to confirm the message was not changed on the way. DKIM is defined in RFC 6376.

DMARC ties the first two together. It checks that the domain in the visible From address matches the domain that passed SPF or DKIM. This match is called alignment. DMARC also tells receivers what to do with mail that fails: do nothing, send it to spam, or reject it. It is defined in RFC 7489.

Sources: IETF RFC 7208 (April 2014), RFC 6376 (September 2011) and RFC 7489 (March 2015), rfc-editor.org.

Why bulk senders need all three

Google's sender guidelines took effect on February 1, 2024. They apply to mail sent to personal Gmail accounts. Every sender needs SPF or DKIM. Bulk senders, meaning anyone whose daily volume to Gmail tops 5,000 messages, need SPF, DKIM and DMARC, and the From domain must align with one of the first two.

The same guidelines ask for more. Senders above that 5,000 mark must also support one-click unsubscribe for marketing mail and show a visible unsubscribe link. All senders should keep the spam rate in Google Postmaster Tools below 0.10% and never let it reach 0.30%. DKIM keys should be at least 1024 bits, and 2048 bits is recommended if your provider supports it.

Even if you send far fewer than 5,000 messages a day, the records help. Without them, mail is more likely to land in spam, and anyone can fake your address more easily.

Sources: Google Workspace Admin Help, "Email sender guidelines", support.google.com/a/answer/81126.

How a small firm can check its setup

You do not need special software. Use these steps.

  • List every service that sends mail as your domain. Common ones are your main mailbox, a newsletter tool, an invoicing tool and a help desk.
  • Look up your domain's TXT records with any free DNS lookup tool. Find the record that starts with "v=spf1". You should have exactly one.
  • Look up the DKIM record for each sender. Its name ends in "._domainkey" and begins with the selector your provider gave you.
  • Look up the record at "_dmarc" followed by your domain. If it is missing, you have no DMARC policy.
  • Send a test message to a Gmail address, open it, choose "Show original", and read the SPF, DKIM and DMARC lines. Each should say PASS.

Sources: Google Workspace Admin Help, "Email sender guidelines"; IETF RFC 7208, RFC 6376 and RFC 7489.

Common mistakes to avoid

The most common SPF mistake is publishing two SPF records. A domain must have only one. If you add a new sender, merge it into the existing record.

The second is going over the lookup limit. RFC 7208 allows at most 10 DNS lookups while a receiver evaluates SPF. Terms such as include, a, mx and redirect count toward it. Go over and the result is a permanent error, which counts as a failure. Each tool you add with an include uses up some of that budget.

The third is forgetting a sender. A tool that sends mail as your domain without DKIM or SPF alignment will fail DMARC once you enforce it.

Sources: IETF RFC 7208, section 4.6.4, rfc-editor.org.

A safe order for rolling out DMARC

Start with the policy set to "none". This changes nothing for your mail. It only asks receivers to send you daily summary reports. The address for those reports goes in the "rua" tag of the record.

Read the reports for a few weeks. They show who is sending mail as your domain and which of those messages pass. Fix any real sender that fails.

When the reports look clean, move to "quarantine". The record can also carry a "pct" tag, so you can apply the policy to only part of your mail at first. Raise it step by step. Move to "reject" when you are confident. DMARC shows whether a message matches its domain. It does not prove the sender is trustworthy, and it does not stop look-alike domains.

Sources: IETF RFC 7489, rfc-editor.org.

Sources

  • Google Workspace Admin Help, Email sender guidelines: https://support.google.com/a/answer/81126
  • IETF RFC 7208, Sender Policy Framework (SPF): https://www.rfc-editor.org/rfc/rfc7208
  • IETF RFC 6376, DomainKeys Identified Mail (DKIM) Signatures: https://www.rfc-editor.org/rfc/rfc6376
  • IETF RFC 7489, DMARC: https://www.rfc-editor.org/rfc/rfc7489