SPF, DKIM, DMARC & ARC: Email Authentication Explained

Email authentication is how receiving servers tell your real mail apart from someone spoofing your domain. Get it right and your legitimate mail lands in inboxes while impersonators get rejected; get it wrong and you either leak a spoofable domain or quietly send your own mail to spam. The four pieces, SPF, DKIM, DMARC, and ARC, work together. This guide explains each, the order to deploy them, and how a gateway like Hermes Secure Email Gateway handles the moving parts for you.

SPF: who is allowed to send

Sender Policy Framework is a DNS TXT record listing the servers authorized to send mail for your domain. A receiver checks whether the sending server is on the list. Two things trip people up:

  • The 10-lookup limit. SPF allows at most 10 DNS lookups to resolve; pile on too many include: entries and the record fails (permerror), taking your authentication down with it.
  • Keeping it current. Every service that sends as your domain (your gateway, marketing tools, ticketing) must be authorized, or its mail fails SPF.

DKIM: proof the message wasn’t forged

DomainKeys Identified Mail adds a cryptographic signature to each message. You publish a public key in DNS at selector._domainkey.yourdomain, and the sending server signs with the matching private key. Receivers verify the signature, which proves the message genuinely came from your domain and wasn’t altered in transit. Unlike SPF, DKIM survives basic forwarding because the signature travels with the message.

DMARC: what to do when checks fail

Domain-based Message Authentication, Reporting & Conformance ties SPF and DKIM together and tells receivers what to do with mail that fails. It also requires alignment: the domain that passes SPF or DKIM must match the visible From: domain, which is what actually stops spoofing. A DMARC record sets a policy:

  • p=none: monitor only; collect reports without affecting delivery.
  • p=quarantine: send failing mail to spam.
  • p=reject: refuse failing mail outright.

DMARC also sends you aggregate reports (rua) so you can see who is sending as your domain before you tighten the policy.

ARC: surviving forwarding and gateways

SPF and DKIM can legitimately break when a message passes through an intermediary, a mailing list, a forwarder, or a security gateway that adds headers or rewrites links. Authenticated Received Chain fixes this: each hop “seals” the authentication results it saw, so the final receiver can trust the original verdict even though the message was modified along the way. ARC is essential any time mail flows through a gateway in front of Microsoft 365 or Google Workspace.

The order to deploy

  1. Publish SPF authorizing every legitimate sender.
  2. Enable DKIM signing and publish the public key.
  3. Start DMARC at p=none and read the reports until you’re confident all your real mail aligns.
  4. Tighten DMARC to quarantine, then reject.
  5. Add ARC if mail passes through a gateway or forwarder.
Where a gateway helps. Doing this per-service is fiddly. A gateway gives you one place to sign DKIM consistently for the whole organization, one egress IP to authorize in SPF, and ARC sealing for mail it relays. Hermes handles the signing and sealing; you manage one clean set of DNS records. → SPF Settings · Authentication docs

Common mistakes

  • Jumping straight to p=reject before confirming your own mail aligns, which is the fastest way to block your own invoices.
  • Forgetting a sender in SPF: marketing, CRM, or helpdesk mail silently fails.
  • Blowing the 10-lookup SPF limit, which fails the whole record.
  • Skipping ARC behind a gateway, so legitimate forwarded mail fails DMARC.

Related

Authentication is also a key step when you put a gateway in front of Microsoft 365 or Google Workspace.

Start a free trial See all features