Authentication & Identity Control

Anyone can put any address in the From line of an email. Authentication lets you prove that mail using your domain really comes from you. This article explains the three checks every mailbox provider runs (SPF, DKIM and DMARC), how to set them up, and the mistakes that break them.

Why authentication matters

SMTP (the protocol servers use to pass email along) was designed when everyone on the network trusted each other. It has no way to check who sent a message. That gap let phishing and spoofing (faking someone else’s address) spread. Three checks, published in DNS, were added on top. Each answers one question:

1. SPF: Is this server allowed to send email for this domain?
2. DKIM: Was this message really signed by this domain, and has it changed since?
3. DMARC: Does the domain the reader sees match the domain that passed? And what should happen if it doesn’t?

Gmail, Yahoo and Microsoft (Outlook.com) require all three from bulk senders (anyone sending 5,000 or more messages a day to their users). Passing them doesn’t guarantee the inbox. Failing them makes the spam folder or a rejection much more likely, and it leaves your domain open to spoofing.

SPF

SPF (Sender Policy Framework) is a DNS record that lists the servers allowed to send email for your domain.

How SPF works

Every email carries two sender addresses. The From address is the one the reader sees. The envelope sender (also called the Return-Path or MAIL FROM) is a hidden address that receives bounces. SPF checks the envelope sender’s domain, not the From address.

Say shop.example sends order emails through an email service provider (ESP). The receiving server:

1. Reads the envelope sender, for example bounce@mail.shop.example.
2. Looks up the SPF record for mail.shop.example in DNS.
3. Checks whether the IP address that connected is on the list.
4. Records a result: pass, fail, softfail, neutral, or an error.

You can see any domain’s SPF record with the DNS lookup tool.

Reading an SPF record

A typical record looks like this:

v=spf1 include:_spf.google.com include:amazonses.com -all

• v=spf1 says “this is an SPF record”. It must come first.
• include:_spf.google.com adds every server listed in Google’s SPF record (for Google Workspace mail).
• include:amazonses.com does the same for Amazon SES.
• -all means “any other server is not allowed”.

Other parts you may see:

ip4:203.0.113.0/24          — allow this range of IPv4 addresses
ip6:2001:db8::/32           — allow this range of IPv6 addresses
a                           — allow the IPs in the domain's A record
mx                          — allow the domain's mail (MX) servers
redirect=_spf.example.com   — use another domain's SPF record instead
-all                        — fail everything else
~all                        — softfail everything else (suspicious, but not a hard no)
?all                        — say nothing about everything else

SPF rules to follow

• Publish only one SPF record per domain. Two TXT records starting with v=spf1 cause an error, and SPF fails.
• Stay under 10 DNS lookups. Each include, a, mx, redirect and exists costs a lookup, and so do the includes inside them. Going over 10 is a permanent error (permerror), and SPF fails. This is the most common SPF problem. ip4 and ip6 don’t cost a lookup.
• Flatten only if you must. Flattening means replacing includes with the IP addresses behind them. It saves lookups, but you must update the record whenever your provider changes its IPs.
• List every service that sends for you: your newsletter tool, CRM, help desk, billing system and office email.
• End with -all or ~all. -all is stricter. ~all is common once DMARC is in place, because DMARC then decides what happens to failing mail. Never use +all, which allows every server on the internet.
• Remove old entries for services you no longer use.

If your ESP uses its own bounce domain, SPF passes for the ESP’s domain, not yours. DMARC alignment, below, deals with that.

DKIM

DKIM (DomainKeys Identified Mail) adds a digital signature to each email. The signature proves which domain signed the message and that nobody changed it on the way.

How DKIM works

DKIM uses a pair of keys. You keep the private key secret on the sending server. You publish the matching public key in DNS, where anyone can read it.

1. The sending server picks some headers (such as From, Subject and Date) and the body.
2. It signs them with the private key and adds the result as a DKIM-Signature header.
3. The receiving server reads that header to find the signing domain (d=) and the selector (s=, the name of the key).
4. It fetches the public key from DNS at selector._domainkey.domain.
5. It uses the public key to check the signature against the message it received.
6. If they match, DKIM passes. If the message was changed, or the key is wrong, DKIM fails.

To create a key pair and the DNS record to publish, use the DKIM key generator.

Reading a DKIM signature

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=shop.example; s=s1;
  h=from:to:subject:date:message-id;
  bh=abc123...=;
  b=xyz789...=;

• d= is the signing domain. DMARC compares this with the From address.
• s= is the selector. It tells the receiver which key to fetch from DNS.
• h= lists the headers that were signed.
• c= is the canonicalization (how strictly whitespace and letter case are compared). relaxed tolerates small changes that servers make in transit.
• a= is the algorithm. rsa-sha256 is the standard. ed25519 is newer, but not every receiver checks it yet, so send an RSA signature too.
• bh= is a fingerprint (hash) of the body, and b= is the signature itself.

You can see the signature on any email you received with the header analyzer.

DKIM rules to follow

• Use 2048-bit RSA keys. 1024 bits is the minimum receivers accept, but it’s getting weak. Some DNS hosts limit TXT record length; split a long key into several quoted strings in the same record.
• Sign with your own domain. Many ESPs sign with their own domain by default (for example d=sendgrid.net). Turn on custom DKIM so the signature says d=shop.example. DMARC needs this.
• Always sign the From header. DKIM requires it. Also sign To, Subject, Date and Message-ID.
• Use relaxed/relaxed. simple breaks on harmless changes, such as a server re-wrapping a long header.
• Check the DNS record. A typo, a missing quote or a cut-off key makes every signature fail.
• Rotate keys every 6 to 12 months. Publish the new key under a new selector. Switch signing to it. Check that mail is signed with the new key. Then remove the old key after a few days.

DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) connects SPF and DKIM to the From address the reader sees. It’s a DNS record that tells receivers three things:

1. How to check alignment: does a domain that passed SPF or DKIM match the From domain?
2. What to do when a message fails: nothing, send it to spam, or reject it.
3. Where to send reports about who is sending email as your domain.

DMARC is defined in RFC 9989 (published in May 2026), which replaced the older RFC 7489. Aggregate reports are defined in RFC 9990.

How alignment works

SPF and DKIM can pass for any domain. A spammer can pass SPF for their own domain while putting your domain in the From line. Alignment closes that gap. A message passes DMARC when at least one of these is true:

• SPF aligns: SPF passed, and the envelope domain matches the From domain.
• DKIM aligns: DKIM passed, and the d= domain matches the From domain.

“Matches” can be relaxed (the same main domain, so mail.shop.example matches shop.example) or strict (exactly the same name). Relaxed is the default and suits most senders.

For an email from orders@shop.example:

• Envelope bounce@mail.shop.example: SPF aligns (relaxed), because it shares the main domain shop.example.
• Envelope bounce@esp-bounces.example: SPF does not align, even if SPF passes.
• DKIM d=shop.example: DKIM aligns.
• DKIM d=sendgrid.net: DKIM does not align.

This is why custom DKIM signing at your ESP matters. It’s usually the easiest way to get an aligned pass.

Reading a DMARC record

You publish DMARC as a TXT record at _dmarc. plus your domain, for example _dmarc.shop.example:

v=DMARC1; p=reject; rua=mailto:dmarc@shop.example; adkim=r; aspf=r

• v=DMARC1 says “this is a DMARC record”.
• p= is the policy for mail that fails: none (just report), quarantine (send to spam) or reject (refuse it).
• rua= is where receivers send aggregate reports: daily summaries, in XML, of who sent email as your domain and whether it passed.
• adkim= and aspf= set alignment for DKIM and SPF: r for relaxed, s for strict.

Optional tags:

• sp= sets a different policy for subdomains.
• np= sets the policy for subdomains that don’t exist, such as fake.shop.example. Spammers like to invent these.
• t=y marks the policy as a test. It asks receivers not to apply it yet while you check your reports.
• ruf= asks for failure reports about single messages. Few providers send them.

The old pct= tag (apply the policy to only some of your mail) was removed in RFC 9989. Receivers that follow the new standard ignore it. Use t=y while you test instead.

Rolling out DMARC

Move to a stricter policy step by step, so you don’t block your own mail:

1. Monitor. Publish p=none with a rua address. Read the reports for two to four weeks. List every service that sends as your domain.
2. Fix. Make sure each real sender (your CRM, help desk, billing tool) passes aligned SPF or DKIM.
3. Quarantine. Change to p=quarantine. You can add t=y at first. Watch the reports for real mail that fails.
4. Reject. When all your real mail passes, change to p=reject. Receivers now refuse mail that fakes your domain.

p=none meets the Gmail and Yahoo minimum for bulk senders, but it doesn’t stop anyone from spoofing you. Only quarantine and reject do.

Keep reading your reports after you reach p=reject. A new tool or an ESP change can quietly break alignment. A DMARC report service turns the XML into something readable.

ARC

Forwarding breaks authentication. When a university forwards a student’s mail to Gmail, the university’s server isn’t in the sender’s SPF record, so SPF fails. If the forwarder adds a footer, DKIM breaks too.

ARC (Authenticated Received Chain) helps here. Each server that handles the message records the authentication results it saw and signs them. The final receiver can then trust the original result, if it trusts the forwarder. Mailbox providers and forwarders run ARC, not senders. Your job is to get SPF, DKIM and DMARC right in the first place.

BIMI

BIMI (Brand Indicators for Message Identification) lets your logo appear next to your emails in supporting inboxes, such as Gmail, Yahoo and Apple Mail. It builds on authentication:

1. Enforce DMARC with p=quarantine or p=reject.
2. Publish a BIMI DNS record that points to your logo, in a special SVG format.
3. Get a mark certificate, such as a VMC (Verified Mark Certificate), which proves you own the logo. Gmail and Apple Mail require one.

BIMI doesn’t change your spam score. It makes your mail easier to recognise.

Checklist

• SPF: one record per domain, listing every service that sends for you, under 10 lookups, ending in -all or ~all.
• DKIM: 2048-bit keys, signing with your own domain (d=shop.example) at every ESP.
• DMARC: a record with a rua address, moving from p=none to p=reject.
• Reverse DNS: each sending IP has a PTR record (a DNS record that maps the IP to a hostname), and that hostname points back to the same IP. ESPs set this up for their IPs.
• TLS: your mail is sent over encrypted connections. Most ESPs do this for you.
• BIMI (optional): once DMARC is enforced.

To check it all at once, send a message to the test inbox and read the SPF, DKIM and DMARC results. Authentication won’t fix a bad list or unwanted content, but every other improvement in this manual depends on it.