Learn how SPF, DKIM, and DMARC protect your business email, what each does, common mistakes, and how to set up authentication correctly for your domain.
Brandset Team16 min de leituraIf your business sends email from its own domain, SPF, DKIM, and DMARC are the three authentication standards that help inbox providers verify that your messages are legitimate. They live in your domain's DNS, usually require a one-time setup, and now matter for businesses of almost every size.
The confusing part is that all three deal with authentication, but they do different jobs.
SPF answers: Is this server allowed to send for this domain? DKIM answers: Was this email signed by an authorized domain, and did the signed content survive transit without being altered? DMARC answers: Does the authentication match the domain the recipient actually sees in the From field, and what should happen when it doesn't?
The Internet Engineering Task Force defines SPF in RFC 7208, DKIM in RFC 6376, and, as of May 2026, DMARC in RFC 9989, which replaced the older RFC 7489 specification.
In short:
Each protocol checks something different — they aren't redundant: SPF authorizes infrastructure. DKIM signs the message. DMARC connects that authentication to the domain your customer actually sees.
DMARC alignment is the part most explanations skip: You can have SPF pass and DKIM pass and still fail DMARC, because passing isn't the same as the authenticated domain matching your visible From address.
Two SPF records is the single most common setup mistake: RFC 7208 doesn't permit multiple SPF records for the same domain — a new provider's instructions should update your existing record, not create a competing one.
Authentication doesn't buy inbox placement: It removes one source of uncertainty. Reputation, complaints, list quality, and sending behavior still do most of the work.
Think about a small design studio called Northstar Studio that sends from hello@northstarstudio.com. The studio uses Google Workspace for normal business email and an email marketing platform for newsletters. Both systems need to send legitimate email using Northstar's domain.
Here is what each authentication method contributes:
Authentication | What it checks | Simple way to think about it |
|---|---|---|
SPF | Whether the sending system is authorized to send for the envelope domain | The approved sender list |
DKIM | Whether a message carries a valid cryptographic signature from an authorized domain | The signed seal |
DMARC | Whether SPF or DKIM aligns with the domain visible in the From address, plus the domain owner's policy | The rule connecting authentication to your visible brand |
These systems work together, but they aren't interchangeable. SPF authorizes sending infrastructure. DKIM signs the email. DMARC connects that authentication to the domain your customer actually sees. For most small businesses sending marketing email from their own domain, setting up all three is the sensible baseline.
You don't configure SPF, DKIM, and DMARC inside the body of an email. You publish information about them in DNS, the Domain Name System.
DNS is the system that lets the internet find services associated with your domain. The same place that can contain records directing visitors to your website can also contain TXT records used for email authentication. You might manage DNS through GoDaddy, Namecheap, Cloudflare, Squarespace Domains, your hosting provider, or another domain registrar. Your email provider usually gives you the values to add — you copy those values into your DNS settings.
That distinction matters. If you use Google Workspace for employee email and another platform for email marketing, both services can affect your authentication configuration. Changing providers without updating DNS is one of the easiest ways to break authentication.
SPF stands for Sender Policy Framework. It tells receiving mail systems which servers are authorized to send email using a particular domain in the SMTP envelope. The SPF standard describes it as a DNS record that declares which hosts are authorized to use a domain for email sending identities.
A simplified SPF record might look something like this:
v=spf1 include:_spf.examplemail.com -all
Do not copy that record to your domain. It is only an example — the actual value depends on the services that send email for you. Suppose Northstar uses Google Workspace and an email marketing platform. Its SPF configuration may need to authorize the infrastructure used by both. If the marketing platform isn't authorized correctly, SPF can fail even though emails sent directly from Google Workspace pass.
SPF does not simply ask "Did this email come from northstarstudio.com?" The technical check is performed against SMTP identities such as the MAIL FROM domain rather than merely the From address people see inside their inbox. This distinction becomes important when DMARC enters the picture.
For a small-business owner, the practical question is simpler: have you authorized every legitimate system that sends email using your domain? That can include employee email, newsletters, transactional messages, CRM emails, website systems, invoicing software, support tools, or other services.
If you already have SPF and a new provider gives you another SPF value, don't automatically create a second SPF record at the same domain. RFC 7208 specifies that an SPF policy is represented by a single SPF string in a DNS TXT record and that multiple SPF records for the same owner name are not permitted. This often happens when a business starts with Google Workspace (v=spf1 include:_spf.google.com ~all), then later adopts another sending platform and creates a completely separate SPF record for it. Now the domain may have two competing SPF policies. Usually the correct job is to update the existing policy so it authorizes the required senders, following the instructions from the services involved.
A business may send email through more systems than the owner realizes. Northstar could have Google Workspace, a marketing platform, a website contact system, a billing service, and a support platform. If any of those systems sends using the domain but isn't properly represented in the authentication setup, some email can pass while other messages fail. Google explicitly tells domain owners that their SPF configuration should include all email senders for the domain.
SPF also has a technical limit that becomes relevant when businesses keep adding services. The SPF standard limits mechanisms and modifiers that cause DNS queries to 10 during evaluation. Exceeding the limit results in a permanent SPF error. This is one reason a long SPF record full of include: statements deserves attention — more services do not always mean you can keep adding another include: forever.
DKIM stands for DomainKeys Identified Mail. It adds a cryptographic signature to an email so the receiving system can verify that an authorized domain signed the message.
The sender uses a private key to sign the message. The corresponding public key is published in DNS. The receiving mail system retrieves that public key and verifies the signature. You don't need to perform the cryptography yourself — your email provider normally creates or manages the signing process. Your job may simply be to publish the DNS record it provides.
SPF and DKIM validate different things. SPF focuses on whether a sending system is authorized. DKIM attaches authentication to the message through a digital signature. That difference becomes especially useful because email doesn't always travel directly from sender to recipient — messages can be forwarded, relayed, or processed by other systems along the way. DKIM also gives DMARC another authentication path to evaluate. A business shouldn't view SPF and DKIM as competing choices. They complement each other.
A DKIM record usually includes a selector. You might see a DNS hostname that looks roughly like selector1._domainkey.northstarstudio.com. The selector tells the receiving system which public key to retrieve. Selectors allow a domain to maintain different DKIM keys for different systems or rotate keys without using one permanent key for everything. This means Northstar could potentially have one DKIM selector associated with Google Workspace and another associated with its marketing email provider. That's normal.
Google currently requires DKIM keys of at least 1024 bits for messages sent to personal Gmail accounts and recommends 2048-bit keys where the domain provider supports them. Yahoo also requires at least 1024 bits and recommends 2048. For a nontechnical business owner, the takeaway is simple: use the key configuration recommended by your email provider rather than generating a shorter or improvised key yourself.
A DKIM failure doesn't automatically mean someone hacked your email. It can happen because the DNS record is incorrect, the wrong selector is being used, the signing service hasn't been configured properly, or a signed part of the message was changed after the signature was created. DKIM verification depends on the receiving system being able to retrieve the proper public key and validate the signature. If DKIM worked before a migration and suddenly fails after changing email providers, check the provider configuration and DNS before changing your newsletter content.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It checks whether authenticated email aligns with the domain visible in the From address and lets the domain owner publish a policy for authentication failures.
This is the piece that connects technical authentication to the brand identity the recipient sees. In May 2026, the IETF published RFC 9989 as the current DMARC specification, replacing RFC 7489 and RFC 9091. DMARC can pass when SPF or DKIM passes and the successfully authenticated domain is aligned with the Author Domain used by the message.
The word alignment is the part most small-business explanations skip. It shouldn't be skipped.
Suppose a customer receives an email that visibly says:
From: Northstar Studio
The person sees northstarstudio.com. DMARC asks whether the successful SPF or DKIM authentication is associated with that same domain or an appropriately aligned domain. So you can have a situation where a technical authentication check passes but DMARC still fails because the authenticated identity and the visible From domain don't line up correctly.
Google requires direct mail to personal Gmail accounts to align the From domain with either the SPF domain or DKIM domain for DMARC. This is one reason simply seeing "SPF=pass" somewhere isn't enough to conclude that the entire authentication setup is correct.
A DMARC record can publish a policy. The three policy values you'll encounter are:
Policy | Practical meaning |
|---|---|
| Monitor DMARC results without asking receivers to change handling because of the DMARC policy |
| Ask receivers to treat failing mail more suspiciously |
| Publish the strongest policy against messages that fail DMARC |
The current DMARC specification treats p=none as monitoring mode and recommends starting there so domain owners can inspect reports and identify legitimate sending systems they may have missed before applying enforcement. A basic monitoring record could look like:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Again, this is an example, not a value to paste blindly into your own DNS. The rua value identifies where aggregate DMARC reports should be sent. Those reports can reveal which systems are sending mail associated with your domain and whether those messages are passing authentication.
It sounds responsible: "If authentication fails, reject everything." That can backfire if your setup is incomplete. Perhaps your newsletter is configured correctly, but your billing platform still sends receipts through another service. Or an old CRM is still sending customer messages. Move directly to strict enforcement and legitimate email may get caught with the unauthorized mail.
The current DMARC specification recommends using reporting to understand mail streams before moving toward stronger enforcement, and it specifically warns about complications with indirect flows such as mailing lists. Monitor first. Find the legitimate senders. Fix them. Then decide how aggressively to enforce the policy.
Return to Northstar Studio. The company sends a newsletter from hello@northstarstudio.com. Its email platform sends the campaign.
SPF can verify whether the relevant sending infrastructure is authorized for the envelope domain. DKIM can verify a cryptographic signature attached to the message. DMARC then evaluates whether the successful authentication aligns with northstarstudio.com, the domain visible to the subscriber. That relationship is why configuring only one record leaves part of the job unfinished — SPF controls authorized infrastructure, DKIM provides domain-backed message signing, and DMARC connects authentication to your visible domain and adds policy and reporting.
You shouldn't wait until your company becomes a "bulk sender" before caring about authentication.
As of August 2026, Gmail requires all senders to personal Gmail accounts to use SPF or DKIM and requires bulk senders to use SPF, DKIM, and DMARC. Google defines the higher-volume requirements around senders exceeding 5,000 messages per day to Gmail accounts. Yahoo's sender requirements tell bulk senders to implement SPF and DKIM and publish a valid DMARC policy, with at least a monitoring policy. Microsoft introduced SPF, DKIM, and DMARC requirements for domains sending more than 5,000 emails per day to Outlook consumer services and began enforcing the high-volume policy in 2025.
A business sending 300 newsletters a week may sit below those high-volume thresholds. That doesn't make authentication pointless. Google recommends setting up SPF, DKIM, and DMARC for sending domains even beyond its minimum requirements because authenticated messages are less likely to be rejected or marked as spam and help protect domains from impersonation. If you control your business domain and use it for marketing email, setting up all three is a reasonable default.
Don't start by copying random DNS records from a tutorial. The exact SPF and DKIM values depend on the services that actually send email for your business. A safer setup sequence is:
Include employee email, email marketing, transactional mail, CRM tools, support systems, billing platforms, and any website service that sends through your domain.
Check whether an SPF record already exists before adding anything. Update the existing policy correctly rather than creating a second SPF record for the same domain. RFC 7208 permits only one SPF policy record for an owner name.
Publish the DKIM record or records supplied by those providers and verify that signing is active. Different services can use different selectors.
Send real test messages through each legitimate route and inspect the authentication results. Google's sender guidance specifically recommends verifying authentication and making sure third-party providers authenticate your domain properly.
Start with a valid p=none policy and aggregate reporting when appropriate. The current DMARC specification recommends this approach so you can find systems that were missed during SPF and DKIM deployment.
Fix legitimate failures first. Once you understand your sending environment, you can make an informed decision about moving from monitoring toward quarantine or rejection.
This is one of those jobs where a conservative sequence beats a fast one.
Adding whatever DNS record the newest tool tells you to add. Every new SaaS product sees only its part of your email setup. Your domain sees all of them. If a new provider tells you to configure SPF, first determine what already exists and what other systems depend on it. Blindly replacing an existing SPF record can fix one sender and break another.
MX records tell other mail systems where incoming mail for your domain should go. SPF deals with authorization for outgoing email identities. Changing MX records is not how you add another newsletter provider to SPF. If you're configuring marketing email and a tutorial suddenly tells you to replace your business's incoming-mail routing without a clear reason, stop and verify the instructions.
This deserves repeating because it is easy to do and easy to miss. You don't normally solve a new sender by creating v=spf1 include:provider-a.example ~all and then another SPF policy beside it, v=spf1 include:provider-b.example ~all. The SPF specification doesn't permit multiple SPF records for the same owner name. The required senders need to be represented correctly in the domain's SPF policy.
DMARC reporting is useful partly because companies often don't know every system sending on their behalf. That old invoicing platform matters. So does the form tool someone installed two years ago. So does the CRM that sends appointment reminders. The current DMARC standard recommends starting in monitoring mode precisely because legitimate senders can be overlooked during initial SPF and DKIM deployment.
SPF, DKIM, and DMARC don't buy you a ticket to the Primary inbox. They establish identity and help receiving systems evaluate your mail. Google explicitly includes authentication alongside other sender requirements such as low spam rates, valid DNS configuration, TLS, message formatting, and unsubscribe behavior. A perfectly authenticated campaign can still generate complaints. You can authenticate email sent to people who never asked for it. You can authenticate irrelevant newsletters. You can authenticate a domain with poor reputation. Authentication removes one large source of uncertainty. It doesn't replace good email practices.
Don't judge authentication by whether one email happened to arrive in your inbox. Inspect the authentication result. Receiving mail systems can expose results showing whether SPF, DKIM, and DMARC passed or failed. Gmail also recommends Postmaster Tools for eligible senders to monitor compliance and delivery-related signals.
For a small business, the useful test is not simply "do we have DNS records with these names?" It is "are the messages we actually send passing authentication?" A record can exist and still be wrong. An SPF record can omit a sender. A DKIM record can exist while signing is disabled. DMARC can be published while neither authentication path aligns correctly. Test every service that sends as your business.
The best SPF, DKIM, and DMARC setup is one you don't have to think about every time you send a campaign. You document which services send email, keep DNS current when tools change, verify authentication after migrations, and review DMARC data before making major policy changes. Then you get back to the work that should consume your attention: sending email people actually want.
The problem becomes harder when subscriber acquisition, forms, CRM data, campaigns, and automations sit in unrelated tools and nobody has a clear picture of how a contact entered the system. Brandset brings email marketing together with forms, CRM, automations, websites, landing pages, and the brand information stored in the Brand Center, giving smaller teams a more organized place to manage that work.
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.