SPF, DKIM, and DMARC: The Trio That Keeps Your Emails Out of Spam

You set up a professional email address. Created [email protected], sent a test message, everything seemed fine. Then weeks later, clients start complaining that your emails never arrive — or worse, they're receiving fraudulent messages pretending to be from your domain.

This isn't an email server problem. It's an authentication problem. And the solution comes down to three DNS records that most administrators ignore until the damage is already done: SPF, DKIM, and DMARC.

Configuring SPF, DKIM, and DMARC is no longer optional. Gmail, Outlook, and Yahoo now require email authentication for domains sending significant volume — and even for smaller domains, missing these records is an open invitation for spam filters and identity abuse.

---

What Each One Does

The three protocols work together, but each solves a different problem. Understanding what each one does is the first step to getting the configuration right.

SPF: Who Can Send on Behalf of Your Domain

SPF (Sender Policy Framework) is a TXT record in DNS that lists which mail servers are authorized to send email using your domain in the From field.

When a receiving server gets an email from [email protected], it queries the DNS of yourcompany.com and checks whether the sending IP is on the authorized list. If it isn't, the email fails SPF verification.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:mail.zoho.com ~all

• v=spf1 — identifies this as an SPF version 1 record
• include: — includes the IP ranges of a specific provider
• ~all — defines what to do with unlisted IPs (~ = softfail, - = hardfail)

The most common problem: using multiple email providers (Google Workspace for internal, Mailchimp for marketing, Zoho for support) without including all of them in SPF. Any unlisted provider will generate failures.

DKIM: The Digital Signature That Proves Authenticity

DKIM (DomainKeys Identified Mail) works like a cryptographic signature on every outgoing email. The mail server uses a private key to sign the message header — and any receiving server can verify that signature using the public key published in the domain's DNS.

The result: the recipient knows the email genuinely came from your legitimate server and that the content wasn't tampered with in transit.

A DKIM record in DNS looks like this:

google._domainkey.yourcompany.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

• google is the selector — a string that identifies which key to use (useful when you have multiple providers)
• _domainkey is the standard protocol suffix
• p= is the RSA public key

The private key lives on your email provider's servers. You never see it — the provider manages it automatically. Your only responsibility is to publish the public key in DNS.

DMARC: The Policy That Ties It All Together

DMARC (Domain-based Message Authentication, Reporting and Conformance) gives the system coherence. It tells receiving servers what to do with emails that fail SPF or DKIM — and requests reports about what's happening with your domain.

A basic DMARC record:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100

• p=none — monitor only, take no action (good starting point)
• p=quarantine — send suspicious emails to spam
• p=reject — reject emails that fail authentication
• rua= — address that receives daily aggregate reports (XML)
• pct= — percentage of traffic the policy applies to

DMARC also introduces the concept of alignment: for an email to pass, the domain in the From field must align with the domain that passed SPF or DKIM. This closes an important gap — without DMARC, an attacker could use SPF from a different domain to pass verification.

---

How to Check if They're Configured

Before creating any records, verify what already exists on your domain. FlashMon's MX Lookup was built exactly for this: it shows MX records, performs a health check on your mail servers, and displays the SPF, DKIM, and DMARC status for any domain — all in a single query.

To check your domain's email authentication:

1. Open the MX Lookup
2. Enter your domain (e.g., yourcompany.com)
3. The tool returns active MX records, the response from each mail server, and any authentication records found

If you want to inspect TXT records individually, the DNS Lookup lets you query by record type. For SPF, look up TXT records at the root domain. For DMARC, query _dmarc.yourcompany.com.

Domains missing SPF frequently end up on spam blacklists. You can check whether yours has already been flagged using the Blacklist Checker.

---

How to Configure Each One

Google Workspace

SPF:

v=spf1 include:_spf.google.com ~all

Add as a TXT record on the root domain (@).

DKIM: In the Google Admin Console, go to Apps → Google Workspace → Gmail → Authenticate email. Generate the DKIM key and publish the provided TXT record in DNS. The default Google selector is google.

DMARC:

v=DMARC1; p=none; rua=mailto:[email protected]

Add as a TXT record at _dmarc.yourcompany.com. Start with p=none to monitor without blocking.

---

Zoho Mail

SPF:

v=spf1 include:zoho.com ~all

DKIM: In the Zoho Mail panel, go to Settings → Organization → Email Configuration → DKIM. Generate the key and publish the TXT record in DNS. The default selector is zoho.

DMARC:

v=DMARC1; p=none; rua=mailto:[email protected]

TXT record at _dmarc.yourcompany.com.

---

Hostinger (hPanel)

SPF:

v=spf1 include:_spf.hostinger.com ~all

DKIM: Hostinger generates DKIM automatically when you set up email. Check under hPanel → Email → Email Settings → DNS Records. If it's not active, enable it from the panel and wait for propagation.

DMARC:

v=DMARC1; p=none; rua=mailto:[email protected]

Add manually in the DNS zone as a TXT record at _dmarc.

---

Common Configuration Mistakes

Multiple SPF Records on the Same Domain

SPF allows only one TXT record per domain. If you have two separate SPF records, receiving servers will ignore one of them — and half your emails will fail. The fix is to consolidate everything into a single record using multiple include: entries:

v=spf1 include:_spf.google.com include:_spf.mailchimp.com ~all

Too Many DNS Lookups in SPF

SPF has a hard limit of 10 DNS lookups per verification check. Each include: counts as one lookup, and nested include: entries count too. Exceeding this limit invalidates the entire record. Use SPF analysis tools to count lookups before publishing.

Setting Up DMARC Before SPF and DKIM Are Working

If you publish p=reject before validating that SPF and DKIM are correctly configured, you'll start rejecting your own legitimate emails. The right order:

1. Publish SPF and DKIM
2. Set DMARC to p=none with a rua address
3. Analyze reports for 2–4 weeks
4. Once you confirm no legitimate emails are failing, move to p=quarantine
5. Then to p=reject

DKIM With the Wrong Selector or an Expired Key

Some providers rotate DKIM keys periodically. If your provider generated a new key and you didn't update the DNS record, all emails will silently start failing DKIM. Check your provider's panel regularly — or monitor with FlashMon's MX Lookup to catch changes before they become problems.

Using ~all When You Should Use -all

~all (softfail) flags the email as suspicious but still allows delivery. -all (hardfail) rejects it. For domains with DMARC set to reject, ~all in SPF is acceptable — DMARC does the heavy lifting. But without DMARC, use -all for domains that should never send email at all (like inactive subdomains).

---

Where to Start Today

If you've never set up email authentication on your domain, here's the safest path:

1. Check your current state with FlashMon's MX Lookup — see what's already there
2. Configure SPF with the providers you actually use
3. Enable DKIM in your email provider's panel
4. Publish DMARC with p=none and an address to receive reports
5. Wait 2 weeks, review the reports, fix anything that surfaces
6. Move DMARC to p=quarantine and then to p=reject

The full setup takes less than an hour to implement. The absence of it can take months to reverse — especially if your domain gets used in phishing campaigns and ends up on blacklists.

Email authentication isn't an optional technical detail. It's the difference between a business that lands in the inbox and one that ends up in spam — or worse, has its identity weaponized by bad actors.

---

Related reading

• Authentication failed or domain already flagged? See how to check if your IP is blacklisted.
• Confirm the underlying DNS setup with the DNS Lookup and MX Lookup tools before editing production records.