Think of them as a passport, a signature, and a border policy. SPF is the list of countries allowed to issue the passport, DKIM is the signature on it, and DMARC tells the border agent what to do when the signature does not match.
SPF, DKIM, and DMARC are three DNS records that together prove an email is really from your domain. SPF lists which servers are allowed to send on your behalf. DKIM adds a cryptographic signature mailbox providers can verify. DMARC tells those providers what to do when SPF or DKIM fail, with a policy of none, quarantine, or reject. Google and Yahoo now require all three for any sender over 5,000 messages per day.
The three records that decide whether your email reaches the inbox or the spam folder, and the enforcement rule that forced every bulk sender to get them right in 2024.
Sender Policy Framework is a TXT record in your DNS that lists every IP address and mail server allowed to send email claiming to be from your domain. When a receiving server gets a message, it checks the sending IP against your SPF record. If the IP is not listed, the message fails SPF.
DomainKeys Identified Mail adds a private-key signature to the headers of every message your servers send. Receiving servers fetch your public key from DNS and verify the signature. If the body or key headers were tampered with in transit, or the signature does not match, the message fails DKIM.
Domain-based Message Authentication, Reporting, and Conformance is the policy record that tells receiving servers what to do when SPF or DKIM fails. Three policies: p=none (just report), p=quarantine (send to spam), p=reject (bounce it entirely). It also sends you aggregate reports so you can see who is spoofing you.
DMARC does not just check that SPF or DKIM passed. It checks that the domain they authenticated matches the domain in the visible From header. A message can pass SPF for mailer.vendor.com but still fail DMARC alignment if the user sees acme.com in their inbox. Alignment is where most new senders get surprised.
Since February 2024, Gmail and Yahoo reject bulk mail (over 5,000 messages per day to their users) that does not have SPF, DKIM, and a DMARC policy of at least p=none with aligned headers. One-click unsubscribe is also required. Senders who miss the requirements see delivery rates collapse within a day of the threshold.
The number one reason email fails authentication is a marketing or CRM vendor sending as your domain without the right DNS records in place. Every tool that sends from you (CRM, marketing automation, support, scheduling, billing, newsletters) needs its own SPF include and DKIM selector, or those messages fail.
Each of the three protocols was added to the email stack over time, and each solves a slightly different problem. SPF came first (2003), DKIM followed (2007), and DMARC was built in 2012 to tie the two together with a policy and a reporting pipeline. Modern mailbox providers evaluate all three on every inbound message, score the result, and route the message accordingly.
SPF lives in your DNS as a TXT record. The value is a list of mechanisms: include:vendor.com pulls another record in, ip4:1.2.3.4 lists a raw address, and -all or ~all closes the record with a hard or soft fail. The record is read on every inbound SMTP connection and matched against the sending IP.
DKIM uses a selector (a short label like s1 or google) that points to a public key in your DNS at selector._domainkey.yourdomain.com. Each service that sends on your behalf publishes its own selector, so revoking one vendor is a matter of removing their selector record, not rotating a single shared key.
DMARC lives at _dmarc.yourdomain.com as a TXT record. The value sets the policy (p=none, quarantine, or reject), the alignment mode (strict or relaxed), the reporting addresses (rua= for aggregate reports, ruf= for forensic), and the percentage of mail the policy applies to during rollout.
When Gmail or Microsoft 365 receives your message, their server reads the SPF record, checks the sending IP, verifies the DKIM signature against the public key, confirms alignment with the From header, looks up your DMARC policy, and applies it. All of this happens in milliseconds, before the message hits the inbox.
The rua address on your DMARC record receives daily XML reports from major providers listing every IP that sent mail claiming to be your domain, with pass/fail counts. Parsed through a dashboard, these reports are how you discover shadow senders, legitimate vendors you forgot about, and real spoofing attempts.
The ruf address receives individual message samples for failures. Most providers no longer send these in volume due to privacy concerns, so the aggregate rua reports are what matters for day-to-day operations. Treat ruf as optional and rua as the mandatory feedback channel.
In October 2023, Google and Yahoo jointly announced new sender requirements effective February 2024. The headline rule: any sender over 5,000 messages per day to their users must have SPF, DKIM, DMARC alignment, and one-click unsubscribe. Senders who missed the deadline watched their delivery rates collapse that same week. The rules formalized what deliverability engineers had been recommending for a decade and raised the floor for anyone running email at scale.
The threshold counts messages to Gmail addresses on one side and Yahoo (plus AOL, Yahoo-owned) on the other, measured per day. A sender hitting 3,000 Gmail users and 3,000 Yahoo users is under the limit at each. Hit 6,000 at either and the full requirements apply. Most B2B senders cross the threshold on launch day.
Prior to 2024, passing either SPF or DKIM was usually enough. The new rules require both pass and align with the From domain. A vendor-sent message that passes SPF for the vendor domain but has no DKIM record on your domain is now rejected at Gmail, where it would have landed in the inbox a year ago.
The DMARC record must exist at _dmarc.yourdomain.com with at least p=none. The record does not have to enforce (quarantine or reject), but it has to be published and parsable. Senders without a DMARC record at all are treated as unauthenticated and routed accordingly.
Bulk messages must include a List-Unsubscribe header and a List-Unsubscribe-Post header so recipients can unsubscribe with one click inside Gmail, no round trip to a landing page. Any sender who leaves this out loses the inbox placement that the SPF/DKIM/DMARC trio was supposed to earn.
Google published a spam-complaint rate ceiling of 0.3 percent in Postmaster Tools, with a hard warning that anything over that number will see throttling. The rate is per-domain and measured over rolling windows, so a bad campaign at the start of the month can tank an entire week of normal traffic afterward.
Before 2024, a sender with half-wired authentication saw gradual degradation. After 2024, the drop is cliff-shaped: messages that would have landed in the inbox on Monday hit the spam folder on Wednesday because a vendor rotated an IP that was not in the SPF include. Monitoring stopped being optional.
Every record is a TXT entry at a specific DNS name. The syntax is strict, the order of mechanisms matters, and most lookup errors are either a missing final mechanism or an SPF record over the ten-DNS-lookup limit. These are the shapes you will paste into Route 53, Cloudflare, GoDaddy, or whatever registrar hosts your zone.
An SPF record starts with v=spf1, lists one or more include: or ip4: mechanisms, and ends with -all (hard fail) or ~all (soft fail). Example: v=spf1 include:_spf.google.com include:servers.mcsv.net ~all. The record must be a single TXT value, not multiple TXT entries on the same name.
A DKIM record lives at selector._domainkey.yourdomain.com with a value like v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB... The p= value is the base64-encoded public key, usually long enough that registrars with 255-char limits require it be split across chunked TXT strings.
A DMARC record lives at _dmarc.yourdomain.com with a value like v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100; aspf=r; adkim=r. The p= is the policy, pct= is the rollout percentage, and aspf/adkim set relaxed or strict alignment.
aspf=r (relaxed) means the SPF domain can be a subdomain of the From domain. aspf=s (strict) requires an exact match. Most senders start on relaxed because vendor services often sign with subdomains. Strict is a hardening step after the aggregate reports are clean.
An SPF record is only allowed ten DNS lookups during evaluation. Chain too many include: mechanisms and the record returns a permerror, which fails authentication for every message. Senders with five or more vendors routinely hit this limit and have to flatten their SPF record into raw IP ranges.
Set DNS TTLs to 300 seconds (5 minutes) while rolling out or rotating records, so a mistake can be fixed quickly. Once records are stable and known good, raise the TTL to 3600 or higher to reduce DNS query load. The TTL is where many senders cut their fix window from hours to minutes.
Most authentication failures are not sophisticated attacks. They are mundane configuration mistakes that nobody notices until the first big campaign bounces. The patterns repeat across every team: a vendor rotates an IP without updating customers, an engineer flattens an SPF record and misses a mechanism, a DMARC policy is tightened to reject before the aggregate reports are clean. Each one is cheap to prevent and expensive to recover from.
Only one TXT record on a name is allowed to start with v=spf1. If a registrar interface lets you add a second one (common after a vendor onboarding), the record set becomes invalid and every message fails SPF. Fix: merge all include: mechanisms into one record.
A sender who publishes p=reject before fixing their alignment problems bounces their own legitimate mail: internal newsletters, invoices, calendar invites, support replies. The rollout path is p=none for two weeks of aggregate-report review, then p=quarantine at pct=10, climbing to pct=100, then p=reject.
A CRM, marketing tool, or support platform asks you to add their DKIM public key to DNS. If you add the record but the vendor side is not finished provisioning, their messages sign with a selector that resolves to nothing, and every message fails DKIM silently. Always verify both sides before activating.
Domains you own but do not send from (acquisitions, misspellings, redirects) are prime spoofing targets. Publish p=reject DMARC records on every parked domain with a null SPF record (v=spf1 -all) so attackers cannot impersonate them. Deliverability engineers call this the parked-domain lock.
The rua reports are the only honest signal of who is sending as your domain. Teams that set up DMARC and never parse the XML miss shadow senders, failed vendor cutovers, and real spoofing. A DMARC monitoring service (or a parser running in-house) is table stakes.
Sending from marketing@yourdomain.com in one tool and marketing@mail.yourdomain.com in another creates alignment confusion. Pick one From domain pattern per channel (transactional, marketing, support) and route every tool through those patterns. The aggregate reports become readable instead of a mess.
A CRM is one of the top three sources of email volume from any revenue team, alongside marketing automation and support. Every email sent from the CRM (sales sequences, meeting notes, follow-ups, nurture campaigns, system notifications) claims to come from a user at your domain. If the CRM is not in your SPF include and does not sign with DKIM, those messages fail authentication the moment Gmail or Yahoo reads them.
A ten-person sales team running moderate outbound hits the 5,000-message Google threshold inside a week. Every sequence message, cadence step, and personalized follow-up is subject to the 2024 rules. A CRM that cannot pass SPF, DKIM, and DMARC alignment is a CRM that sends your reps to the spam folder.
Marketing campaigns are the highest-volume, lowest-tolerance channel. A missing DKIM selector on a marketing automation tool shows up as a 40 percent drop in opens overnight. The CRM has to coordinate with the marketing tool so both channels sign with aligned domains and both include-mechanisms stay inside the ten-lookup limit.
System emails (invoice generated, deal closed, meeting booked, document signed) are low volume but high stakes. They route through a transactional provider that signs with its own DKIM selector. The CRM has to be configured so those messages pass DMARC alignment against your From domain, not the provider domain.
When a CRM sends through each rep's Gmail or Microsoft 365 mailbox (via OAuth), authentication is handled by the mail provider and the records are already in place. When the CRM sends on their behalf through a shared relay, those relay IPs need to be in the SPF record and the DKIM selector needs to be published.
When a message bounces for authentication reasons, the CRM should surface the failure to the rep or marketer who sent it, not swallow it. Teams running on CRMs that hide bounce diagnostics discover the authentication problem weeks after it started, during the pipeline review that explains the quiet quarter.
Every new email-sending tool is a DNS change: a new SPF include, a new DKIM selector, maybe a new DMARC subdomain. A CRM that documents its exact records (the include: string, the selector, the From-domain alignment) in its admin UI saves the one-hour support ticket per tool, per cutover.
Strkr publishes the exact SPF include and DKIM selectors you need, surfaces bounce diagnostics to the reps and marketers who sent them, and keeps the whole revenue motion aligned with your DMARC policy. Start free and send your first authenticated sequence today.
Yes, if you want your email to reach the inbox at Gmail, Yahoo, or Microsoft 365. SPF without DKIM leaves your messages vulnerable to being modified in transit. DKIM without SPF leaves your sending servers unauthenticated. Neither alone lets mailbox providers apply a consistent policy on failures, which is what DMARC adds. Google and Yahoo now require all three for any sender over 5,000 messages per day.
SPF checks that the sending server is on your approved list. DKIM checks that the message itself was signed by your private key and not tampered with in transit. SPF validates the envelope (the SMTP connection), while DKIM validates the message content (the headers and body). A spoofed sender can sometimes pass SPF by relaying through an authorized server, but they cannot fake a DKIM signature without the private key.
p=none tells receiving servers to apply no action on authentication failures and just send you aggregate reports. p=quarantine tells them to route failures to the spam folder. p=reject tells them to bounce the message outright. The recommended rollout is to start at p=none, monitor reports for two to four weeks, move to p=quarantine at a low percentage, climb to 100 percent, then promote to p=reject once failures are all shadow senders you no longer care about.
Any DNS lookup tool shows the records. The simplest check is to send an email to a Gmail address, open the message, click the three-dot menu, and choose Show Original. Gmail prints the SPF, DKIM, and DMARC result for that message. For continuous monitoring, use a DMARC aggregator that parses your rua reports into a dashboard. Most paid tools in the space do this for a monthly fee.
The receiving server applies whatever policy your DMARC record specifies. If the policy is p=none, the message is still delivered but logged in the aggregate report. If the policy is p=quarantine, the message is routed to the spam folder. If the policy is p=reject, the message is bounced and never seen by the recipient. The sender may or may not get a bounce notification depending on how the provider handles rejections.
Yes, and most companies do. Each service publishes its own SPF include: and its own DKIM selector. Your SPF record aggregates the includes, each DKIM selector gets its own TXT record at selector._domainkey, and one DMARC record covers the whole domain. The main constraint is the ten-DNS-lookup limit on SPF, which forces senders with many vendors to flatten their record or use a hosted SPF service.
No. They stop attackers from spoofing your exact domain, which closes one major attack vector. They do not stop lookalike domain attacks (yourc0mpany.com instead of yourcompany.com), compromised legitimate accounts, or social engineering through unrelated channels. Email authentication is one layer of a security program, not the whole program.
Both providers announced the change in October 2023 and enforced it in February 2024 to reduce the volume of spam and phishing hitting their users. The rules formalized what deliverability engineers had been recommending for a decade: authentication, alignment, one-click unsubscribe, and a cap on spam complaints. The change moved authentication from a best practice to a hard requirement for anyone sending at scale.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
