SPF DKIM DMARC: Business Email Authentication Without the Guesswork

Professional email on your own domain is one of the highest-trust signals a small business can send. It is also the easiest thing to misconfigure, because three DNS records must agree with each other before inboxes start trusting you. SPF, DKIM and DMARC are not optional extras; they are the difference between a sale and a spam folder.

What each record does

SPF — who may send as your domain

SPF is a TXT record listing the servers allowed to send email for your domain. Receivers check the sending IP against that list. You get exactly one SPF record per domain, which is why "too many SPF records" is such a common failure: two records means SPF cannot be evaluated at all.

DKIM — proof the message was not altered

DKIM adds a cryptographic signature to each outgoing message. The public key lives in DNS, so receivers can verify that the message came from your infrastructure and was not modified in transit. Every sending service needs its own selector.

DMARC — what to do when both fail

DMARC ties SPF and DKIM together and tells receivers how to treat mail that fails both. It also sends you reports, which is how you discover what is legitimately sending as your domain.

Start in monitoring mode

Never begin at p=reject. Start here:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100

Leave it at p=none for at least two weeks. Read the aggregate reports. You will usually find three things: your main mail provider (expected), a website contact form (expected but often unsigned), and something you forgot about, such as an old newsletter tool or a CRM.

Align before you enforce

DMARC passes only when SPF or DKIM passes and aligns with your domain. A sending service that uses its own bounce domain will pass SPF but fail alignment. Either move it to a subdomain or configure DKIM for your domain on that service.

Move to quarantine, then reject

Once reports are clean:

1. Change to p=quarantine; pct=25, watch for a week.
2. Raise pct to 50, then 100.
3. Move to p=reject.

Keep rua reporting on permanently. DMARC is not a one-time setup; it is an ongoing inventory of who sends as you.

The mistakes that cause real outages

• Two SPF records. Merge them into one, staying under ten DNS lookups.
• DKIM selector deleted during a migration. Keep old selectors for at least thirty days.
• Mailboxes on a different provider than the MX record. Verify MX points to the provider that actually holds the inboxes.
• Forwarding loops. Forwarded mail often fails SPF. Use a forwarding service that rewrites the sender or keeps DKIM intact.

Test before you announce

Send a test message to a Gmail address and inspect the original. You should see spf=pass, dkim=pass and dmarc=pass. Do the same for Outlook. If any of the three fails, fix that record before rolling out to the team.

Repeat this test after every change to your sending stack. A CRM trial, a new contact form plugin or a switched newsletter provider can all add an unauthorised sender, and with SPF, DKIM and DMARC already enforced, that sender fails quietly until someone notices the bounce reports.

Then make it usable

Authentication gets you into the inbox; the mailbox experience keeps your team productive. Enable two-factor authentication, set up aliases for roles such as support@ and billing@, and document who owns each alias.

A worked example

Suppose your domain sends mail from three places: your main mailbox provider, a website contact form, and a CRM. Start with one SPF record that includes all three mechanisms, then give each service its own DKIM selector:

v=spf1 include:_spf.mailprovider.com include:_spf.forms.example.net include:_spf.crm.example.com -all

Keep the total DNS lookups under ten — that is the hard limit in the SPF specification. If you exceed it, mail fails without any obvious error, which is why "include" chains should be audited every year.

Then publish DKIM selectors such as s1, forms and crm, and keep every selector in DNS as long as the service may still send. Removing a selector early is one of the most common causes of sudden deliverability drops.

Monitoring after enforcement

Once you are at p=reject, review reports monthly. Add a ruf address only if you can process forensic reports; they are verbose and often contain personal data. Aggregate reports from rua are enough for most businesses.

The payoff is measurable: fewer spam-folder placements, fewer spoofed invoices using your name, and better placement for transactional mail such as password resets. The DMARC specification overview covers the syntax if you want the authoritative reference.

Ready to move? Explore HostingBeyond business email or read more email guides.