TL;DR. Email started in the 1980s as a protocol that took the sender at their word. Forty years later we have three layered standards — SPF, DKIM, and DMARC — that let receiving servers (and you) verify whether a message really came from the domain it claims. As of 2024 and 2025, all of the major mail providers require these for senders who want their mail delivered. If you have ever wondered what those acronyms actually do, why a domain has to publish a DNS record to send mail in 2026, or how to look at a message right now and confirm whether it is authentic — this is for you.

How we got here: from open relays to layered authentication

The early years — trust by default

The original SMTP standard (RFC 821) was published in 1982. It did exactly what its name suggests: a sending server connected to a receiving server and handed off a message. There was no mechanism for a receiver to verify that the message really came from the domain in the From: header. If the sending server said the mail was from This email address is being protected from spambots. You need JavaScript enabled to view it., the receiving server believed it. The internet was small, the participating organizations all knew each other, and trust by default was the only practical design.

That design started to break almost immediately as the network grew. Spammers in the 1990s and early 2000s discovered they could connect to badly-configured mail servers (so-called open relays) and send mail through them claiming to be from any domain they liked. There was no way to prove otherwise.

SPF (2006) — "this domain only sends mail from these servers"

Sender Policy Framework was the first widely-adopted answer. The owner of a domain publishes a DNS record listing the IP addresses or servers authorized to send mail on its behalf. When a receiving server gets a message claiming to be from yourcompany.com, it looks up yourcompany.com’s SPF record. If the IP that delivered the mail is on the list, SPF passes; if not, SPF fails.

SPF closed off the open-relay problem and is still essential. Its limitation is that it only checks the envelope sender — the SMTP-level MAIL FROM address — not the visible From: header that users see. A malicious sender can pass SPF on one domain while displaying a totally different domain to the user. SPF alone is not enough.

DKIM (2007/2011) — "this message has not been altered, and was signed by this domain"

DomainKeys Identified Mail works differently. The sending mail server uses a private key to sign each outbound message; the public key is published in DNS at selector._domainkey.yourdomain.com. The receiving server pulls the public key, checks the signature, and confirms two things:

1. The signing domain really did sign this message.
2. The body and protected headers have not been altered in transit.

DKIM is the cryptographic backbone of modern email authentication. Modern recommendations are 2048-bit RSA keys (older 1024-bit keys are still widely deployed but considered weak); the public key lives in a DNS TXT record with a chosen selector name. Microsoft 365, for example, uses two selectors (selector1 and selector2) so it can rotate keys automatically. Google Workspace defaults to a selector named google.

DMARC (2015) — "and tell receivers what to do when SPF or DKIM fails"

Domain-based Message Authentication, Reporting, and Conformance is the policy layer that ties SPF and DKIM together and gives the domain owner two superpowers:

1. Tell receiving servers what to do when authentication fails. A DMARC record can specify p=none (do nothing), p=quarantine (treat as spam), or p=reject (refuse the message outright). It also enforces alignment — the domain in the visible From: header has to match the SPF or DKIM domain, closing the SPF gap.
2. Get reports back. The rua= parameter in a DMARC record tells receiving servers where to email aggregate reports of authentication results. Those reports show every IP that tried to send mail claiming to be from your domain — legitimate senders and impostors alike.

Newer additions

The story did not end with DMARC. Subsequent standards layer additional protection on top:

• ARC (Authenticated Received Chain, 2019) — preserves authentication results when messages are forwarded through mailing lists or other intermediaries that would otherwise break DKIM.
• MTA-STS — lets a domain say “always require encrypted (TLS) delivery for my inbound mail.”
• BIMI (Brand Indicators for Message Identification) — once you have DMARC at p=quarantine or p=reject, BIMI lets your verified company logo show up next to your messages in supporting clients (Gmail, Apple Mail, Yahoo Mail).

What the major providers actually require in 2026

This is no longer optional. As of the last two years, every major mailbox provider has hard requirements for senders:

• Google (Gmail / Workspace) — effective February 1, 2024. Every sender to Gmail must have either SPF or DKIM. Bulk senders (more than 5,000 messages per day to Gmail) must have SPF, DKIM, and DMARC (DMARC can start at p=none) plus a one-click unsubscribe and a spam-complaint rate under 0.3%. As of November 2025 Google began outright rejecting non-compliant mail.
• Yahoo — the same requirements, on the same timeline. Google and Yahoo published a joint sender policy.
• Microsoft (Outlook.com, Hotmail, Live.com) — effective May 2025. Microsoft followed with similar rules: bulk senders to consumer Microsoft addresses must have SPF, DKIM, and DMARC.
• Apple (iCloud Mail) — Apple has long honored DMARC and increasingly requires it for delivery to iCloud addresses, including those on personal-domain iCloud Mail subscriptions.

Translation: in 2026, if your domain is not properly authenticated, your legitimate mail is being delayed, junked, or dropped on the floor by the providers most of your customers and partners use.

What a DKIM record actually looks like

A DKIM record is a DNS TXT record at a specific subdomain that includes the public key. A typical example for a custom domain:

Name:  selector1._domainkey.example.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0hZ...truncated...QIDAQAB

The pieces:

• v=DKIM1 — version.
• k=rsa — key algorithm. RSA is universal; some providers also support Ed25519 now.
• p=... — the actual base64-encoded public key. 2048-bit is the modern standard.

For Microsoft 365 specifically, you publish two CNAME records pointing selector1._domainkey and selector2._domainkey at Microsoft-managed targets, and Microsoft hosts the actual TXT records on its side — that lets Microsoft rotate your keys without you doing anything. For Google Workspace you generate the key pair in the admin console and publish the resulting TXT record yourself.

The public key is just that — public. It is safe to publish in DNS. The matching private key never leaves your mail provider.

Third-party senders: HubSpot, Mailchimp, and friends

The single most common reason SMB email authentication is broken is third-party senders. Almost every business sends mail from at least one platform that is not their primary mailbox provider:

• Marketing automation: HubSpot, Mailchimp, ActiveCampaign, Constant Contact, Klaviyo
• CRM and sales: Salesforce / Marketing Cloud / Pardot, Zoho, Microsoft Dynamics, Apollo, Outreach
• Transactional email: SendGrid, Mailgun, Postmark, Amazon SES, Resend
• Help desk and ticketing: Zendesk, Freshdesk, Intercom, ConnectWise PSA, RSTickets
• Payments and invoicing: Square, Stripe, QuickBooks Online, FreshBooks, PayPal
• HR, scheduling, e-signature: BambooHR, Calendly, Acuity, DocuSign, Adobe Sign
• Productivity and forms: SharePoint/OneDrive notifications, Microsoft Bookings, Microsoft Forms, Google Forms

Each of those platforms wants to send mail with your domain in the visible From: field — This email address is being protected from spambots. You need JavaScript enabled to view it., not This email address is being protected from spambots. You need JavaScript enabled to view it. — so the message looks like it came from you. For that to also pass SPF, DKIM, and DMARC, you have to authorize the platform to sign as your domain.

How third-party DKIM normally works

Almost every reputable email platform now follows the same pattern: they generate a DKIM key pair, host the public key on their own DNS, and ask you to publish a CNAME record at a selector under your domain that points to their hosted key. That way they can rotate their keys without bothering you, and your DNS only has a CNAME (one-time setup).

The result, in the receiver’s headers, is something like:

dkim=pass header.i=@yourcompany.com header.s=hs1-12345 header.b=...

The signing domain is yours, the selector belongs to the platform, and the message authenticates as legitimately from your domain.

Provider-specific quick reference

• HubSpot — in the HubSpot account, go to Settings › Marketing › Email › Configuration › Connect a sending domain. HubSpot generates two CNAME records (typically named hs1-XXXXX._domainkey and hs2-XXXXX._domainkey) plus a redirect domain CNAME. Publish all three in your DNS, click Verify, and HubSpot will sign your outbound mail with DKIM. HubSpot also asks you to update your SPF record to include spf.hubspotemail.net (or similar).
• Microsoft 365 — primary mail provider for most of our clients. Two CNAMEs (selector1._domainkey and selector2._domainkey) pointing to Microsoft-hosted targets, plus an SPF entry of include:spf.protection.outlook.com. DKIM is not on automatically — you have to enable it in the Defender portal after the CNAMEs are in place.
• Google Workspace — generate the key pair in the Google Admin console (Apps › Google Workspace › Gmail › Authenticate email), publish the resulting TXT record under google._domainkey, then click Start authentication. SPF: include:_spf.google.com.
• Mailchimp — under Domains, set up your sending domain; Mailchimp gives you two CNAMEs (typically k1._domainkey and k2._domainkey) plus a DMARC alignment record.
• Constant Contact — under My Account › Self-Authenticate Your Email, you receive a CNAME (cc-...._domainkey) and an SPF include of spf.constantcontact.com.
• SendGrid — Sender Authentication › Domain Authentication. Three CNAMEs (typically em####, s1._domainkey, s2._domainkey). Once verified, all SendGrid mail signed as your domain authenticates cleanly.
• Salesforce / Marketing Cloud / Pardot — Salesforce ships a tool called Sender Authentication Package (SAP) that walks you through the SPF and DKIM CNAME setup for each Salesforce sending domain.
• Zendesk / Freshdesk / Intercom — each has a “custom email domain” or “allowlist sender” flow that asks you to add a CNAME (zendesk1._domainkey, etc.) plus an SPF entry. Skipping this is why so many help-desk emails from custom domains land in spam.
• Square / Stripe / QuickBooks — transactional senders for invoices and receipts. Square recently added domain-authentication support; until you configure it, invoice emails go from a This email address is being protected from spambots. You need JavaScript enabled to view it. address rather than your own — legitimate, but easy for customers to mistake for spam.

SPF gotcha: SPF has a hard limit of 10 DNS lookups per record. Each include: entry counts against that limit, and large platforms (HubSpot, Salesforce, etc.) can chain 2–3 lookups internally. Stack five or six platforms and you blow through the SPF lookup limit, which causes all of your SPF checks to fail with a permerror. The fix is either pruning to current senders only, or running the SPF record through a flattening / SPF-macro service that consolidates the lookups.

The DMARC alignment trap

One more wrinkle: DMARC requires alignment — the domain in the visible From: header has to match the domain that signed with DKIM or the domain in the SPF envelope. Some third-party senders default to using their domain in the envelope and only sign with their own DKIM, which means SPF and DKIM both pass technically but DMARC fails because nothing aligns to your visible From:. The fix is to enable the platform’s “sender authentication” feature so they sign with your domain’s DKIM, which gives you DKIM alignment.

If you have ever seen a HubSpot or Salesforce email that arrived with the warning “sent on behalf of” or “via hubspot.com,” that is the alignment failure showing up in the receiver’s UI. Setting up the platform’s domain authentication makes it go away.

How to verify a message yourself

Every modern mail client lets you see the message’s headers, including the Authentication-Results line that records SPF, DKIM, and DMARC verdicts. Here is how, and what to look for:

Gmail (web)

1. Open the message.
2. Click the three-dot menu next to the reply arrow › Show original.
3. Gmail displays a summary at the top: SPF: PASS, DKIM: ’PASS’ with domain ..., DMARC: ’PASS’. The full raw headers are below.

This is the easiest verification on the planet. Send yourself a message from your domain to a Gmail address and look at Show original. If you see all three PASSes, your authentication is doing its job — that is exactly the test the customer who prompted this article ran on his own domain. (Send mail from your work account to your personal Gmail. Look at Show original. Done.)

Outlook on the web (outlook.office.com)

1. Open the message.
2. Click the three-dot menu › View › View message details.
3. Look for the Authentication-Results header. It will list spf=pass, dkim=pass, dmarc=pass (or fail) along with the domain that signed.

Apple Mail (macOS)

1. Open the message.
2. View › Message › All Headers (or ⌥⌘U). The Authentication-Results header is in the list.

Reading Authentication-Results

The line itself is the receiver telling itself (and you) what it concluded. A typical legitimate result looks like:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=selector1 header.b=AbCdEf;
       spf=pass (google.com: domain of This email address is being protected from spambots. You need JavaScript enabled to view it. designates 40.92.0.5 as permitted sender) smtp.mailfrom=This email address is being protected from spambots. You need JavaScript enabled to view it.;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

What to look at:

• All three pass. If dkim=pass, spf=pass, and dmarc=pass all appear, the receiver is satisfied the message is authentic.
• The header.from domain matches what the user sees. If the visible “From” says This email address is being protected from spambots. You need JavaScript enabled to view it. but header.from says This email address is being protected from spambots. You need JavaScript enabled to view it., that is a tell.
• DMARC policy. p=REJECT means the domain owner has put the strongest policy in place — a fake claiming to be from this domain would be rejected.

If dkim=fail or dmarc=fail shows up on a message you were expecting from a real partner, the most likely cause is a misconfiguration on their side — their list provider, marketing tool, or new mail server is not authorized in their SPF/DKIM. We see this on customer engagements regularly. The fix is on their end, but you may need to nudge them.

How to know if your domain is authenticated

The thirty-second test is the one our customer ran: send an email from your work domain to a Gmail account, open it in Gmail, and click Show original. If you see SPF: PASS, DKIM: 'PASS', and DMARC: 'PASS', you are in good shape. If any of them say FAIL, NEUTRAL, or NONE, your domain is not fully authenticated and you should fix it before too many of your messages start going to spam folders — or worse, getting rejected outright.

If you would rather not interpret headers yourself, free online tools like MXToolbox’s SuperTool will look up your SPF, DKIM, and DMARC records and tell you whether each is present and well-formed.

What to do if your domain is not yet authenticated

The order to do it in:

1. Inventory who actually sends mail for you. Your mail provider (M365 or Google), plus any newsletter platform, CRM, ticketing system, or web form that sends from your domain.
2. Publish SPF listing all of those senders. Use ~all initially, tighten to -all once you are sure the list is complete.
3. Enable DKIM at your primary mail provider and publish the DNS records they give you. On Microsoft 365 specifically, this is not on by default for custom domains — you have to turn it on in the Defender portal and publish two CNAMEs.
4. Publish DMARC at p=none with a rua= reporting address. Watch the reports for two to four weeks.
5. Move DMARC to p=quarantine and then p=reject once the reports are clean.

If any of that sounds like a project you would rather not own, drop us a line or call 970-282-8838 and we will run it for you. We do this fairly often — it is the cheapest cybersecurity win available to a small business right now.