SPF, DKIM, and DMARC are essential email authentication protocols that verify sender identity, prevent domain spoofing, and are now required by Gmail and Yahoo for most senders.
Brandset Team13 min de leituraSPF, DKIM, and DMARC sound like infrastructure acronyms because they are. You do not need to become an email administrator to understand why they matter.
Email authentication helps receiving providers verify that a message is authorized to use a domain and gives domain owners more control over impersonation. SPF, DKIM, and DMARC each handle a different part of that job.
They also matter increasingly for ordinary marketing operations. Gmail and Yahoo now require authentication from senders, with stricter requirements for bulk senders.
Authentication still does not guarantee the inbox. A perfectly authenticated email can land in spam if the broader sending behavior gives providers reasons to treat it as unwanted. The useful way to think about authentication is simpler: it establishes who is allowed to speak for your domain before reputation, complaints, content, and recipient behavior enter the picture.
In summary:
SPF — which servers are allowed to send mail for your domain.
DKIM — a cryptographic signature confirming the message wasn't altered and came from a system with access to your domain's private key.
DMARC — checks whether that authentication aligns with the domain the recipient actually sees in the From field, then publishes a policy for what to do when it doesn't.
The catch: authentication is now mandatory for many senders, but passing it doesn't guarantee inbox placement. It's a prerequisite, not a delivery guarantee.
Protocol | What it does | Simple analogy |
|---|---|---|
SPF | Identifies servers authorized to send mail for a domain used in the message delivery path | The approved sender list |
DKIM | Adds a cryptographic signature that can verify the signing domain and whether signed parts of the message changed | A signed tamper seal |
DMARC | Checks whether authenticated domains align with the visible From domain and publishes a policy for failures | The policy connecting identity checks to your brand |
They work together, but they are not interchangeable. Understanding that distinction makes the setup much less mysterious.
Suppose your company is Acme Studio. Sending marketing email from hello@acmestudio.com gives Acme control over the DNS records for the domain. That is what allows the business to publish its own SPF, DKIM, and DMARC configuration.
A free address such as acmestudio@gmail.com works differently. Google owns gmail.com. Google can authenticate mail for that domain. Acme cannot publish a new SPF or DMARC policy for gmail.com because Acme does not control its DNS.
For a business establishing its own sending identity, use a domain you control. That gives you the ability to authenticate the domain properly and maintain that identity even if your email provider changes later.
SPF stands for Sender Policy Framework. An SPF record is published in DNS and identifies the systems authorized to send email for a domain.
Suppose Acme uses Google Workspace for employee email, Brandset for marketing campaigns, and another service for transactional messages. Those services need to be accounted for correctly in Acme's sending configuration.
When an email reaches a receiving server, SPF can be used to determine whether the sending IP is authorized by the SPF policy for the relevant envelope-sender domain. That wording matters — SPF does not simply inspect the address a person sees beside "From:" and confirm that it belongs to the sender. Email has several identities behind the scenes. The visible From address and the domain SPF authenticates are not necessarily the same. DMARC is what later connects those identities through alignment.
A common SPF mistake: businesses sometimes add a new email provider by creating another SPF record. That can break the configuration. A domain should normally have one SPF policy that includes the authorized sending sources it needs. If you change email providers, add a transactional service, or stop using an old platform, SPF deserves another look. Do not copy random SPF strings from a blog post — the correct value depends on the services that actually send mail for your domain.
DKIM stands for DomainKeys Identified Mail. Instead of authorizing a sending IP, DKIM uses cryptography.
The sending system adds a DKIM signature to the email headers. That signature references a domain and a selector. A corresponding public key is published in DNS. When a mailbox provider receives the message, it can use that public key to validate the signature.
A successful validation provides evidence that the message was signed by a system with access to the domain's private DKIM key, and that the signed portions of the message have not been modified in a way that invalidates the signature. Recipients do not normally see any of this — it happens in the message headers and during authentication checks.
DKIM does not mean "this email is good." A spammer could theoretically authenticate a domain they legitimately control. DKIM tells the receiving system something important about identity and integrity. It does not tell Gmail that the recipient wants the message. This distinction runs through all three protocols: authentication establishes technical legitimacy. Deliverability still depends on the broader sending relationship.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. This is the part that often gets oversimplified as "DMARC tells Gmail what to do when SPF or DKIM fails." That is incomplete.
DMARC also introduces alignment. For DMARC to pass, the domain visible to the recipient in the From header needs to align with a domain that successfully authenticated through SPF or DKIM. Google's current requirement for bulk senders illustrates this directly: the organizational domain in the From header must align with either the SPF-authenticated domain or the DKIM-authenticated domain.
Consider a visible From address of newsletter@acmestudio.com. If DKIM successfully signs with an aligned acmestudio.com domain, DMARC can pass through DKIM. If the SPF-authenticated domain is also aligned with acmestudio.com, DMARC could pass through SPF. Only one aligned mechanism needs to pass for DMARC to pass, although both SPF and DKIM should be configured correctly where required.
A DMARC record publishes a policy using the p= value. There are three options.
p=none. Commonly used during initial deployment and monitoring. It tells receivers that the domain owner is not requesting quarantine or rejection of messages that fail DMARC. It can be paired with reporting configuration so the domain owner can analyze authentication activity before moving toward enforcement. DMARC.org recommends beginning with p=none, reviewing the reports, correcting legitimate mail streams, and then increasing enforcement when appropriate. This setting does not guarantee that a message will reach the inbox — the receiver can still classify or reject mail for other reasons.
p=quarantine. The domain owner requests that receivers treat messages failing DMARC with greater suspicion, commonly by placing them in spam or another quarantined state. It is stronger enforcement than p=none.
p=reject. The domain owner requests rejection of messages that fail DMARC. This provides stronger protection against straightforward domain spoofing once legitimate sending sources have been properly configured and aligned. DMARC.org describes p=reject as a request for receivers to reject non-aligned messages — the word request is important. Email receivers ultimately control how they process incoming mail, and real-world email forwarding and authentication scenarios can be more complicated than the three-policy summary suggests.
Imagine a message with a visible From address of offers@acmestudio.com. Behind the scenes, an unrelated sending system authenticates successfully using randommailer.example. SPF may pass for randommailer.example. That alone does not prove that the system should be allowed to represent acmestudio.com.
DMARC asks whether the authenticated identity aligns with the domain the recipient actually sees. This closes an important gap: the visible brand cannot simply borrow authentication from an unrelated domain and call itself authenticated. That is one reason DMARC became such an important part of modern sender requirements.
These standards are not theoretical best practices anymore.
Gmail currently requires senders to personal Gmail accounts to use SPF or DKIM. It also requires valid DNS configuration, TLS, RFC-compliant formatting, and spam rates below its stated thresholds.
Senders reaching roughly 5,000 messages or more to personal Gmail accounts within 24 hours are classified as bulk senders — this threshold applies specifically to personal @gmail.com addresses, not Google Workspace business accounts, which follow their own administrative policies. Gmail requires those senders to use SPF, DKIM, DMARC, From-domain alignment, one-click unsubscribe for applicable marketing and subscribed messages, and additional technical and spam-rate requirements. Google allows the required DMARC policy to begin at p=none. Once Gmail classifies a primary domain as a bulk sender, that classification is permanent — sending less afterward does not reverse it.
Yahoo follows a similar structure. All senders must authenticate using at least SPF or DKIM. Yahoo requires bulk senders to use both SPF and DKIM and publish a valid DMARC policy with at least p=none, along with alignment and unsubscribe requirements. Yahoo deliberately does not publish a fixed numeric threshold for what it considers a bulk sender.
For a small business well below these thresholds, the lesson is still straightforward: set authentication up while the program is simple.
There is no universal sequence that looks like "missing SPF → low trust → spam → damaged reputation." Mailbox systems are more complicated than that.
What can happen is easier to state. A provider may be unable to verify that the sending system is authorized. The message may fail authentication requirements. Bulk mail may violate explicit Gmail or Yahoo sender rules. Messages may be rejected, rate-limited, or placed in spam. Legitimate email can also fail DMARC if authentication was configured incorrectly.
Google says unauthenticated messages can be marked as spam or rejected, and its enforcement for noncompliant bulk traffic includes temporary and permanent failures. Yahoo likewise documents authentication failures as a possible reason for permanent delivery errors.
Authentication is therefore both a security issue and an operational deliverability requirement.
It can make direct spoofing significantly harder when properly configured and enforced.
Suppose an attacker sends from billing@acmestudio.com, but the message does not come from an authorized Acme sending source and does not have aligned authentication. A correctly configured DMARC policy can instruct participating receivers to quarantine or reject that message. That is valuable protection.
It is still too strong to say that p=reject makes impersonation impossible. Attackers can use lookalike domains like acme-studio-payments.com. They can compromise legitimate accounts. They can impersonate display names. Not every phishing attempt depends on directly spoofing your exact domain.
DMARC solves an important part of email impersonation. It does not solve phishing as a whole.
This may be the most important distinction in this guide.
DMARC.org explicitly notes that DMARC itself is not an inbox-placement system. Correctly implementing DMARC does not automatically change whether legitimate mail is considered spam. Google makes a similar distinction through its sender guidance — authentication is required, but Google also evaluates complaints, sending behavior, message practices, DNS configuration, volume changes, and other factors.
So an email can be perfectly authenticated — SPF pass, DKIM pass, DMARC pass — and still reach spam. The sender may be mailing people who never requested the messages. Complaint rates may be high. The domain may have an unhealthy sending history. The company may have suddenly activated a large old list.
Authentication confirms identity. It does not create recipient permission or interest.
Return to Acme Studio, sending a newsletter from newsletter@acmestudio.com.
Step 1 — SPF. The receiving server checks whether the sending infrastructure is authorized under the relevant SPF domain.
Step 2 — DKIM. The receiver checks the cryptographic signature and confirms whether the DKIM authentication passes.
Step 3 — DMARC. DMARC checks whether a successful SPF or DKIM identity aligns with the visible acmestudio.com From domain.
Step 4 — Policy. If DMARC fails, the published DMARC policy tells the receiver whether the domain owner is requesting no enforcement, quarantine, or rejection.
Step 5 — The provider still evaluates the email. Passing authentication does not end filtering. The mailbox provider can still consider reputation, complaints, sending patterns, message characteristics, and other signals when deciding how to handle the email.
That is the full picture. And it's what shows up in the message headers on the receiving end — visible if you know where to look (in Gmail, "Show original"):
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of newsletter@acmestudio.com
designates 192.0.2.10 as permitted sender)
smtp.mailfrom=newsletter@acmestudio.com;
dkim=pass header.i=@acmestudio.com header.s=selector1
header.b=Xk3jf9...;
dmarc=pass (p=REJECT sp=REJECT dis=NONE)
header.from=acmestudio.com
Three independent checks, each reported separately, each feeding into the receiving provider's broader spam evaluation. A failure looks the same structurally — spf=fail, dkim=fail, or dmarc=fail — but what happens next depends on the published policy and everything else the provider knows about the sender.
If you use your own domain for marketing email, check these basics.
Know every legitimate service that sends for your domain — employee email, marketing software, transactional systems, billing tools, support tools, or other platforms. Forgotten senders become important once enforcement increases.
Configure SPF correctly. Make sure legitimate sending services are covered by the SPF configuration without creating conflicting SPF policies.
Enable DKIM. Use the DNS records and setup process provided by your email service. Google currently accepts DKIM keys of at least 1024 bits as the minimum for mail sent to personal Gmail accounts, but recommends 2048-bit keys as the standard where your provider supports them. Yahoo follows the same pattern — 1024 bits accepted, 2048 recommended. If your email platform lets you choose, default to 2048.
Publish DMARC. Begin with an appropriate policy for your current setup. If you are uncertain whether every legitimate sender is correctly aligned, monitoring before stronger enforcement can prevent you from blocking your own mail.
Review alignment. Make sure the domain recipients see in the From address aligns with at least one successfully authenticated SPF or DKIM identity.
Test before assuming it works. Send test messages and inspect authentication results. A DNS record existing does not automatically mean the entire mail flow is passing correctly.
Review the configuration when your stack changes. New email provider, new transactional service, migration, or old platform removed — authentication should be part of the change.
You should not configure SPF because you expect it to increase your open rate by five points. You configure it because sending systems need a verifiable identity.
You do not publish DMARC because it magically places campaigns in the primary inbox. You publish it because aligned authentication and an explicit domain policy make impersonation harder and are now part of the requirements major mailbox providers impose on many senders.
Those are stronger reasons than a deliverability hack.
For small teams, the frustrating part is that DNS authentication sits outside the creative work they actually wanted to do. Brandset guides senders through connecting and authenticating their sending domain while maintaining the sending infrastructure behind the platform. The business still controls its domain, its subscriber relationships, its list quality, and the messages it chooses to send.
That division of responsibility matters. Brandset can provide the sending system and authentication guidance. The sender still has to earn trust from the people receiving the email.
Brandset Team25 min de leituraLearn how to plan, segment, write, design, and measure effective email campaigns for small businesses, focusing on strategy, relevance, deliverability, and post-send analysis.
Brandset Team11 min de leituraLearn how to clean your email list effectively by separating inactive, bounced, and unsubscribed contacts, using multiple engagement signals, and avoiding loss of good subscribers.