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

Yes, in practice. Major mailbox providers such as Google and Yahoo now expect bulk senders to authenticate with SPF and DKIM and publish a DMARC policy, and it is good practice for every business domain. Each record covers a different weakness, and DMARC only works when at least one of the other two passes and aligns with your domain.

Will setting up DMARC stop my emails from being delivered?

Not if you roll it out gradually. Start with a monitoring policy of p=none, read the reports for a few weeks to find every legitimate sender, fix their SPF and DKIM, and only then move to quarantine and reject.

Why do my emails still go to spam after setting up SPF and DKIM?

Authentication proves who sent a message but does not guarantee it is wanted. Sending reputation, content, list quality, complaint rates, a missing unsubscribe link on marketing mail, or a blocklisted server IP can all still push messages into spam.

What happens if I have two SPF records?

The SPF check fails with a permanent error, which mailbox providers treat as if you had no valid SPF at all. Merge all your authorized senders into a single TXT record that starts with v=spf1.

Should marketing email be sent from the same domain as company email?

Many businesses use a subdomain such as news.example.com for marketing and bulk sending. That keeps the reputation of newsletters separate from day-to-day company mail, so a campaign problem does not affect invoices and customer replies.

Email Deliverability: SPF, DKIM and DMARC Explained

A quote goes out, the client never sees it, and the deal stalls for a week before anyone realises it is sitting in a spam folder. Problems like this are rarely about the wording of the email. Far more often, the receiving server could not verify that the message really came from your business. Improving email deliverability with SPF, DKIM and DMARC is the foundation: three DNS records that tell the world which servers may send for your domain and what to do with impostors. This guide explains each one in plain language, shows how they fit together, and gives a safe rollout plan.

Why authentication matters more every year

Email was designed without any built-in way to prove who sent a message. Anyone can put your domain in the "From" line. Mailbox providers have responded by trusting unauthenticated mail less and less, and the large providers now publish explicit requirements for domains that send in volume.

For a business, weak authentication causes two separate problems:

Your genuine mail is treated as suspicious, so it lands in spam or is rejected.
Criminals can spoof your domain to send fake invoices or password-reset messages to your customers and suppliers.

SPF, DKIM and DMARC address both problems together.

SPF: which servers may send for you

Sender Policy Framework (SPF) is a TXT record on your domain that lists the servers and services allowed to send email using that domain.

A typical record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

Reading it left to right: this is an SPF record; Google Workspace, SendGrid and one specific server may send; everything else should fail.

Common SPF mistakes

More than one SPF record. You may only have one. Two records cause a permanent error.
Too many DNS lookups. SPF allows a maximum of ten lookups when evaluating include and similar mechanisms. Stacking many services can exceed this limit and break the record.
Forgetting a sender. The website's contact form, the CRM, the accounting software and the helpdesk may all send mail as your domain.
Using +all. This authorizes the entire internet to send as you. It should never appear.

SPF has one important weakness: it checks the hidden "envelope" sender, not the "From" address people see. That is why DKIM and DMARC are needed.

DKIM: a tamper-proof signature

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every outgoing message. Your sending service holds a private key; you publish the matching public key in DNS under a "selector", for example s1._domainkey.example.com.

When a message arrives, the receiving server fetches the public key and checks the signature. If it verifies, the receiver knows two things: the message was signed by someone controlling that key, and the signed parts were not altered on the way.

DKIM good practice

Enable DKIM on every service that sends for you, not only your main mailbox provider.
Use 2048-bit keys where the provider supports them.
Rotate keys periodically using a new selector, then retire the old one.
Make sure the signing domain is your own domain (or a subdomain of it), not the provider's default domain. This matters for DMARC alignment.

DMARC: the policy that ties it together

Domain-based Message Authentication, Reporting and Conformance (DMARC) does three jobs:

It requires that SPF or DKIM not only pass, but also align with the domain in the visible "From" address.
It tells receivers what to do with mail that fails: nothing, send it to spam, or reject it.
It asks receivers to send you reports showing who is sending mail using your domain.

A starting record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1

Policy	What receivers do with failing mail	When to use it
`p=none`	Deliver normally; send reports	First weeks, while discovering senders
`p=quarantine`	Usually route to spam/junk	Once legitimate senders all pass
`p=reject`	Refuse the message	Final goal for strong protection

Key takeaway: SPF says which servers may send, DKIM proves the message was not altered, and DMARC checks both against the visible sender and tells the world what to do with fakes. You need all three working together.

A safe rollout plan

Jumping straight to p=reject can silently block your own invoices. Use a staged approach instead:

Inventory every sender. List mailbox hosting, website forms, CRM, marketing platform, billing, helpdesk, scanners and any internal servers.
Publish or fix SPF so it includes every legitimate sender in a single record and stays under the lookup limit.
Enable DKIM with your own domain on each service.
Publish DMARC at p=none with a reporting address.
Read the aggregate reports for several weeks. They are XML files, so use a report viewer or service to make them readable. Look for legitimate sources that fail.
Fix the failures by adding missing senders or enabling DKIM.
Move to p=quarantine, optionally with pct= to apply it to a portion of mail first.
Move to p=reject once reports are clean, and keep monitoring.

Beyond the three records

Authentication gets you through the door; reputation and hygiene keep you there.

Server and infrastructure checks

Reverse DNS (PTR) for any server you run yourself should resolve to a hostname that resolves back to the same IP address.
TLS encryption should be enabled for sending and receiving.
Blocklist monitoring catches problems early, especially on shared servers where another customer's behaviour can affect your IP.

If you are deciding where your mailboxes should live in the first place, our comparison of hosted servers, Google and Microsoft covers the trade-offs.

Sending behaviour

Separate bulk and transactional mail, ideally with a subdomain for newsletters.
Include a working unsubscribe link in marketing email. In Canada, commercial messages must also respect CASL consent and identification rules — get professional advice if you are unsure how they apply to you.
Remove addresses that bounce, and do not buy lists.
Keep website form notifications sending through an authenticated service rather than the web server's default mail function.

Special cases that often break authentication

A few situations cause most of the confusing failures we see in DMARC reports:

Forwarding. When a recipient automatically forwards your message elsewhere, SPF usually fails at the final destination because the forwarding server is not in your record. DKIM normally survives, which is one more reason to sign everything with DKIM.
Mailing lists. Some lists modify the subject line or add a footer, which breaks the DKIM signature. Modern list software often rewrites the "From" address to avoid this; older setups may not.
Third-party platforms using their own domain. If a booking system or survey tool sends with its own envelope domain and signs with its own DKIM key, the message may pass SPF and DKIM but still fail DMARC alignment. Most reputable platforms let you configure a custom sending domain — use it.
Subdomains. DMARC policy applies to subdomains by default unless you set a separate sp= value. Unused subdomains are a favourite target for spoofing, so they should be covered by your policy.
Domains that never send email. Parked or secondary domains should publish an SPF record of v=spf1 -all and a DMARC record of p=reject, so nobody can impersonate them.

Diagnosing a deliverability problem

When a specific message goes missing, work through these checks in order:

Ask the recipient to look in spam, quarantine and any filtering gateway their company uses.
Look at the full message headers of a test email to a Gmail or Outlook account. The Authentication-Results header shows whether SPF, DKIM and DMARC passed.
Confirm the sending service is included in SPF and signing with your domain.
Check whether your sending IP or domain appears on major blocklists.
Review recent changes — a new marketing tool, a DNS edit, a server move — which are often the cause.

Next steps

Email authentication is a one-time project with ongoing benefits, but it touches DNS, every sending platform and sometimes your web application. DigiVort sets up and monitors SPF, DKIM and DMARC as part of our hosting and email services, and our security and compliance work covers domain spoofing protection more broadly.

If your important messages keep going missing, contact us and we will review your domain's records and reports and give you a clear, prioritized fix list.

Business Email Deliverability: SPF, DKIM and DMARC Explained