How Email Authentication Works

When you send an email from your business domain (say, you@yourcompany.com), the receiving mail server (Gmail, Outlook, Yahoo) asks three questions before deciding whether to put it in the inbox or spam:

1. Is this server allowed to send email for yourcompany.com? (SPF)
2. Was this email tampered with in transit? (DKIM)
3. What does yourcompany.com want us to do with emails that fail these checks? (DMARC)

These answers live in your domain's DNS records — the same system that maps your domain to your website. If the records are missing, wrong, or outdated, your legitimate emails get treated like spam or phishing attempts.

On top of that, the receiving server checks whether your mail server's IP address is on any blacklists — databases of IPs known to send spam. Even if your authentication is perfect, a blacklisted IP means your email gets blocked.

In plain English: SPF is a list you publish that says "these servers are allowed to send email on behalf of my domain." It's like giving a guest list to a bouncer — anyone not on the list gets turned away.

How it works technically: You add a TXT record to your domain's DNS that lists authorized IP addresses and third-party services. When a server receives an email claiming to be from your domain, it checks this record. Example:

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

This says: "Google and SendGrid can send for us. Everyone else should be rejected (-all)."

What breaks:

• No SPF record — anyone can forge your domain. Major deliverability hit.
• Too many DNS lookups (10 max) — SPF has a hard limit. Each include: counts as a lookup. If you use many services (Google + Mailchimp + SendGrid + HubSpot), you can hit this limit and SPF breaks entirely.
• +all — this means "allow anyone to send as my domain." It's the worst possible setting. Sometimes added accidentally during setup.
• Multiple SPF records — you can only have one. If there are two, both get ignored.

In plain English: DKIM is a digital signature. Your email server stamps every outgoing email with a cryptographic signature, and the receiving server checks the stamp against a public key in your DNS. If the email was altered in transit (by a hacker, a misconfigured server, or a mailing list), the signature breaks and the email looks suspicious.

How it works technically: Your mail server signs the email headers and body with a private key. The matching public key lives in a DNS TXT record at a "selector" subdomain (e.g., google._domainkey.yourcompany.com). Each email service you use gets its own selector.

What breaks:

• No DKIM configured — emails aren't signed. Not a fatal problem alone, but significantly hurts your reputation with receiving servers.
• Missing selectors for a service — you added SendGrid to SPF but forgot to set up its DKIM selector. The emails pass SPF but fail DKIM.
• Rotated keys not updated — some providers rotate keys periodically. If the DNS record is stale, signatures fail.

In plain English: DMARC tells receiving servers what to do when an email fails SPF and DKIM checks. Think of it as the rule book: "If someone sends a fake email pretending to be us, here's what you should do with it."

The three policies:

• p=none — "Do nothing, just send me reports." Good for monitoring, but doesn't protect you.
• p=quarantine — "Put suspicious emails in spam." Good middle ground.
• p=reject — "Block them completely." The gold standard. Stops phishing attacks using your domain.

The reporting addresses:

• rua — aggregate reports. Daily XML reports showing who sent email as your domain and whether it passed/failed. Useful for spotting unauthorized senders.
• ruf — forensic reports. Per-message failure reports. Most providers don't send these anymore for privacy reasons.

What breaks:

• No DMARC record — anyone can spoof your domain with no consequences. This is how phishing emails pretend to be from your company.
• p=none forever — you're monitoring but not protecting. Many people set this during initial setup and never graduate to quarantine or reject.
• No rua address — you're flying blind. No way to know if someone is spoofing your domain.

In plain English: MX records tell the internet where to deliver email addressed to your domain. They point to your mail server (Google, Microsoft, etc.). Without them, replies to your emails bounce — the internet literally doesn't know where to send them.

How it works technically: MX records have a priority number and a hostname. Lower priority = preferred. If the primary server is down, email falls back to higher-priority records.

10 alt1.aspmx.l.google.com
20 alt2.aspmx.l.google.com

What breaks:

• No MX records — your domain can't receive email at all. Customer replies bounce.
• Pointing to a dead server — records exist but the server is offline.
• Changed providers without updating — you switched from Google to Microsoft but MX still points to Google.

In plain English: Blacklists are databases of IP addresses that have been caught sending spam. When you send an email, the receiving server checks your mail server's IP against these lists. If you're on one, your email gets blocked or sent to spam — regardless of how good your SPF/DKIM/DMARC setup is.

The blacklists that matter:

• Spamhaus — the most impactful. Gmail, Microsoft, and Yahoo all check it. If you're on Spamhaus, you have a serious problem.
• SpamCop — user-reported spam. Listings are temporary (24-48 hours) but indicate a real problem.
• Barracuda — widely used by corporate email filters.
• SURBL — checks domains (not IPs) found in spam message content.

How you get listed:

• Sending to purchased or scraped email lists
• High bounce rates (sending to invalid addresses)
• Users marking your emails as spam
• Compromised server sending spam without your knowledge
• Shared IP with another sender who spams (common with cheap hosting)

How to get delisted: Each blacklist has its own removal process. Spamhaus requires you to identify and fix the root cause before they'll delist. SpamCop listings expire automatically. MailReady's AI analysis gives you specific delisting steps for each blacklist you're on.

MailReady checks five things and gives each a pass, warn, or fail:

1. SPF — is it present, valid, and not misconfigured?
2. DKIM — are your signing keys set up for each service?
3. DMARC — do you have a policy, and is it strong enough?
4. MX — can your domain receive email?
5. Blacklists — is your mail server IP clean?

Each check contributes to an overall score that maps to an A-F letter grade. Certain critical issues cap your maximum grade:

• No SPF or DMARC record — max grade C
• Multiple SPF records or 10+ lookups — max grade D
• SPF set to +all — locked at F
• Listed on 3+ blacklists — max grade D

Email authentication isn't "set it and forget it." Things break silently:

• Someone adds a new email service (marketing tool, CRM, support desk) but forgets to update SPF/DKIM
• A team member changes DNS records and accidentally deletes the DMARC record
• Your mail server IP gets blacklisted because of a compromised account or shared hosting
• A service provider rotates DKIM keys and the old DNS record becomes stale
• SPF lookup count creeps past 10 as you add more services over time

MailReady's monitoring ($29/mo) scans your domain daily, compares against the previous scan, and emails you immediately if anything changes — with severity grading so you know what's urgent (blacklist listing, SPF set to +all) vs. informational (new DKIM selector detected).