SPF, DKIM, and DMARC for Ecommerce: A Plain-English Guide

SPF, DKIM, and DMARC sound like alphabet soup right up until a launch campaign lands in spam or a scammer starts impersonating your store.

Together, these email-authentication standards help receiving mail systems decide whether a message claiming to come from your domain is legitimate. They also make it harder for someone to use your brand in a phishing campaign. All three matter, but they do different jobs.

The 30-second explanation

Method	What it does
SPF	Identifies which systems may send mail for a domain
DKIM	Adds a cryptographic signature that a receiver can verify
DMARC	Connects SPF or DKIM to the domain people see in the From address and publishes a handling policy

Authentication proves a relationship between the message and a domain. It does not prove that people asked for the message or want to read it. You still need permission, relevant content, and a healthy list.

SPF

SPF stands for Sender Policy Framework. You publish an SPF record in DNS to identify that the server is allowed to send using a particular envelope domain.

It matters because an ecommerce business rarely sends from one system. Campaigns may come from an email platform, staff mail from Google Workspace or Microsoft 365, receipts from the store platform, and support replies from a help desk. Review, loyalty, referral, and back-in-stock apps may send too.

Every legitimate source that uses the relevant domain needs to be accounted for. At the same time, old services should be removed so they are no longer authorized.

Two common SPF mistakes are publishing more than one applicable SPF record and creating a record that triggers too many DNS lookups. The current IETF SPF specification says a domain must not publish multiple records that would be selected for one check, and it limits lookup-causing mechanisms and modifiers to 10 during evaluation. Follow each provider’s current instructions instead of pasting in a record from an old tutorial.

DKIM

DKIM stands for DomainKeys Identified Mail. Your sending service signs selected parts of an outgoing message with a private key. The receiver retrieves the corresponding public key from DNS and checks the signature.

A successful check shows that the signing domain took responsibility for the message and that the signed content has not changed since it was signed. The IETF DKIM standard describes both the DNS key lookup and what that integrity check does.

Each sending platform normally gives you a TXT record or CNAME to add to DNS. Adding it is only half the job. DKIM may also need to be enabled inside the platform in order for it to work correctly.

Google requires DKIM keys of at least 1,024 bits for mail sent to personal Gmail accounts and recommends 2,048 bits when the domain provider supports it, according to its sender guidelines.

For many third-party ecommerce tools, DKIM is the simplest path to DMARC alignment; however, only when the service signs with your domain.

DMARC

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. Its most important idea is alignment. An email message must pass SPF or DKIM using a domain that aligns with the domain in the visible From address.

The domain owner can also publish a requested policy for messages that fail:

• p=none asks for no DMARC-based change to delivery, making it useful for monitoring.
• p=quarantine asks receivers to treat failures as suspicious.
• p=reject asks receivers to reject failures.

Receivers ultimately apply their own local policies, so these are requests rather than absolute commands. The current IETF DMARC specification, RFC 9989, defines alignment and policy behavior. Domain owners can also request aggregate data about authentication results; that reporting format is covered by RFC 9990.

Why “SPF passed” may not be enough

Imagine that a customer sees hello@example.com in the From field. Your email platform passes SPF using its own return-path domain and signs DKIM with its own shared domain. SPF and DKIM may both pass, yet DMARC can still fail because neither authenticated domain aligns with example.com.

The solution is to configure the provider’s branded return path, custom sending domain, or DKIM signing domain so at least one passing method aligns with the visible From domain.

Google requires direct mail from bulk senders to align the From domain with either the SPF or DKIM domain. Its sender FAQ recommends aligning both when possible.

Gmail’s current sender requirements

Google applies these rules to mail sent to personal Gmail accounts:

• All senders must authenticate with SPF or DKIM.
• Senders of more than 5,000 messages a day to Gmail accounts must use SPF, DKIM, and DMARC.
• For those bulk senders, direct mail must pass DMARC alignment.
• Marketing and subscribed messages from bulk senders must support one-click unsubscribe.
• Senders must use TLS, valid forward and reverse DNS, and properly formatted messages.
• Google recommends keeping the spam rate reported in Postmaster Tools below 0.1% and says it should never reach 0.3% or higher.

Google counts messages from the same primary domain toward the 5,000 threshold and says a sender that meets the threshold once remains classified as a bulk sender. Because enforcement and details can change, check the official Gmail sender guidelines and sender FAQ before changing production DNS.

A safer way to set everything up

Treat authentication as an inventory project.

1. List every service that sends email using your brand’s domains
2. Record the visible From domain, SPF envelope domain, and DKIM signing domain for each one
3. Remove services that no longer send
4. Configure SPF and DKIM from each provider’s current documentation
5. Send a real test through every platform and inspect the message headers
6. Publish DMARC with p=none and aggregate reporting
7. Review reports for legitimate services you missed and sources you do not recognize
8. Fix authentication and alignment problems
9. Move toward p=quarantine or p=reject only when you are confident legitimate mail passes

Do not jump straight to p=reject because it sounds more secure. If order confirmations, password resets, or support messages are not configured correctly, strict enforcement can interfere with mail customers need.

Mistakes worth checking twice

• Publishing multiple applicable SPF records
• Forgetting a legitimate sender or leaving an old one authorized
• Exceeding SPF’s 10-lookup evaluation limit
• Adding a DKIM record in DNS but not enabling signing in the platform
• Passing DKIM with a provider domain that does not align with your From domain
• Publishing DMARC without reviewing reports
• Enforcing quarantine or rejection before every legitimate stream passes
• Forgetting subdomains and low-volume transactional services
• Testing one campaign and assuming every other system works the same way

How to check a real message

Send a test from each platform to a mailbox you control. In Gmail, open the message, select “Show original,” and inspect the SPF, DKIM, and DMARC results. Do not stop at the word “PASS.” Check which domains passed and whether one aligns with the domain in the visible From address.

Google Postmaster Tools can show authentication and reputation data for mail reaching Gmail. DMARC aggregate reports can reveal other systems using your domain, though many businesses use a DMARC reporting service to turn the XML files into something easier to review.

The simple version is still the useful one: SPF identifies permitted senders, DKIM signs the message, and DMARC connects that proof to the domain your customer sees. Configure all three, test every sending stream, and tighten enforcement carefully. Then keep earning inbox placement with the things authentication cannot provide such as permission, relevance, and trust.