How to set up DMARC/DKIM/SPF for Gmail
Published 5 Aug 2026
Updated 12 Oct 2026
13 min read
Summarize with
Updated on 12 Oct 2026: We updated the Gmail setup steps for current DMARC rollout rules, DNS verification, and external report authorization.
For a custom domain using Gmail through Google Workspace, publish one SPF TXT record that authorizes Google, generate and activate a 2048-bit DKIM key in the Google Admin console, then publish a DMARC TXT record at _dmarc. Start DMARC at p=none while you inspect reports. Personal addresses ending in @gmail.com cannot use custom SPF, DKIM, or DMARC records because Google controls gmail.com DNS.
Email authentication is a domain-wide DNS change. Inventory every service that sends with your From domain before editing DNS, because an incomplete SPF record or an unrecognized sender becomes risky when DMARC enforcement starts.
Gmail sender authentication requirements
Google requires SPF or DKIM for mail sent to personal Gmail accounts. Bulk senders need both SPF and DKIM, plus DMARC with at least p=none and a passing SPF or DKIM domain that matches the From domain. Review the Gmail sender guidelines for these requirements.
Google counts close to 5,000 messages or more within 24 hours across the same primary domain, including its subdomains. Once classified as a bulk sender, the domain keeps that status. Google explains this in its sender guidelines FAQ.
Add and verify your Google Workspace domain
Add and verify the domain in Google Workspace before configuring authentication. You need a super administrator account and access to the domain's authoritative DNS. If the domain is already verified and Gmail is active, continue to the SPF checks.
- Open domains: In the Google Admin console, open Account, Domains, then Manage domains.
- Choose the domain type: Select Add a domain. Use Secondary domain for separate user addresses or User alias domain for aliases on existing users.
- Copy the token: Start verification and copy the unique Google TXT verification value.
- Publish the TXT record: Add it at the root of the domain in your DNS provider, save it, then return to Google and select Verify.
- Confirm status: Wait until Manage domains shows the domain as verified before changing MX or authentication records.
Google Workspace Admin console showing a verified custom domain
Domain verification is separate from mail routing
A verified domain proves ownership, but Gmail will not receive mail until its MX records are active. Keep the old MX route in place until users and data are ready, then change MX during a controlled cutover.
Set up SPF
SPF authorizes the servers allowed to use your domain in the SMTP return path. If Google Workspace is your only sender, publish Google's include at the root of the domain. Follow Google's SPF setup steps when your DNS host needs provider-specific fields. SPF does not inherit to subdomains. Publish a separate SPF record for each subdomain actually used as an SMTP MAIL FROM domain.
First search the root TXT records for an existing value beginning with v=spf1. At a given hostname, publish only one SPF record. If one exists, add Google's include inside that record instead of publishing a second SPF TXT record.
Google Workspace only
- Host: Use @ or leave the host blank, depending on the DNS provider.
- Type: Publish one TXT record.
- Value: Use Google's standard SPF record shown below.
Google plus other senders
- Inventory: List every service using your From domain.
- Merge: Keep one v=spf1 record and add each documented sender mechanism before ~all.
- Limit: Keep SPF within the ten-term DNS lookup limit, including nested include and redirect evaluations.
SPF record for Google Workspace onlyDNS
v=spf1 include:_spf.google.com ~all
Check the published result after DNS has updated. The result should show one SPF record with valid syntax. Count nested includes and redirects toward the ten-term limit specified in RFC 7208; counting only the include tags visible in your record misses those nested evaluations.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
A pass only proves that the connecting server can use the return-path domain. DMARC also compares that domain with the visible From domain. Google Workspace supports a matching return path for normal Gmail sending, but a third-party relay or forwarding route can change it.
- One record: Remove duplicate SPF TXT records and merge authorized senders.
- No copied IP list: Use include:_spf.google.com so Google's changes are inherited.
- No unsupported guesswork: Add another provider only when its current documentation tells you to.
- DKIM fallback: If a sender cannot use your domain in its return path, expect SPF alignment errors. That is acceptable when its DKIM signature passes with your From domain.
Google recommends ~all for its SPF record. It returns SPF softfail for unlisted servers; -all returns fail. The receiving server decides how to handle either result. Changing ~all to -all does not replace DMARC enforcement.
Set up DKIM
DKIM authenticates outgoing Gmail messages with a digital signature tied to your custom domain. If DKIM already passes for that domain, keep the working key. Otherwise, generate a separate key for each Workspace domain and use 2048 bits when your DNS provider accepts long TXT values. After Gmail is activated, Google can take 24 to 72 hours before a new DKIM key is available in the Admin console.
- Open Gmail settings: In the Google Admin console, go to Apps, Google Workspace, Gmail, then Authenticate email.
- Select the domain: Choose the custom domain that will appear in the From header.
- Generate the key: Select Generate new record and choose 2048-bit. Use the default selector google if it is unused; choose a different selector if an existing key already uses google.
- Publish the key: Create the TXT record at google._domainkey and paste the complete value Google provides. If you chose another selector, replace google with that selector in the host name.
- Start signing: After DNS resolves, return to Authenticate email and select Start authentication.
Google Workspace DKIM setup with a 2048-bit key and google selector
DKIM DNS fieldsDNS
Host: google._domainkey Type: TXT Value: paste the complete value generated by Google
Do not stop after publishing DNS
The TXT record publishes the public key, but Gmail does not sign with your custom-domain key until Start authentication is selected. The final Admin console status should say "Authenticating email with DKIM".
DNS providers sometimes split a long 2048-bit value into quoted chunks. That is valid when the chunks remain inside one TXT record. Do not create separate TXT records for each chunk. Use the 1024-bit option only if your DNS host cannot support a 2048-bit key. Follow Google's DKIM setup instructions for the key options.
Set up DMARC
DMARC checks whether SPF or DKIM passes with a domain that matches the visible From domain. The published policy requests how receivers handle DMARC failures. Participating receivers send aggregate XML reports to the rua address so you can find legitimate and unauthorized sources. A p=none policy requests monitoring without DMARC enforcement; it does not guarantee inbox delivery.
Create a dedicated reporting address first. Aggregate reports can be numerous and are difficult to read manually. Google's DMARC setup guidance recommends allowing SPF and DKIM to authenticate messages for at least 48 hours before enabling DMARC, and authenticating every third-party sender before enforcement. DMARC is published in DNS; no Google Admin console switch is required.
- Set the host: Create the TXT record at _dmarc.example.com, replacing example.com with the domain used after @ in the From address. If your DNS provider appends the domain automatically, enter only _dmarc.
- Start with monitoring: Use p=none and the starter record below, replacing dmarc@example.com with your working mailbox or report collection address.
- Keep enforcement: If your current policy is p=quarantine or p=reject, keep it. Do not weaken a working policy to p=none.
- Save one record: A domain can have only one DMARC TXT record at _dmarc. Merge tags instead of creating duplicates.
Starter DMARC recordDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
The DMARC record generator can build the TXT value for subdomain policies or stricter domain matching. Relaxed matching (aspf=r and adkim=r) is the default. For From: user@example.com, a passing DKIM signature with d=mail.example.com qualifies under relaxed matching; adkim=s requires d=example.com.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Run the check against the domain used in the From address, such as example.com or news.example.com. Confirm that the parsed policy, report address, and syntax match what you intended.
|
|
|
|---|---|---|
SPF | example.com (@) | Authorize MAIL FROM senders |
DKIM | google._domainkey.example.com | Publish the DKIM public key |
DMARC | _dmarc.example.com | Publish policy and reporting address |
Authentication records for a Google Workspace domain
Leave p=none in place long enough to observe normal traffic patterns. A low-volume domain needs more calendar time than a busy domain to expose occasional senders such as billing systems or support workflows.
Authorize external DMARC reports
Sending aggregate reports to another domain requires external reporting authorization. If example.com uses rua=mailto:dmarc@example.net, the owner of example.net must publish the TXT record below in example.net DNS. Without authorization, receivers following RFC 9990 ignore that report destination.
External report authorization in example.net DNSDNS
Host: example.com._report._dmarc Full name: example.com._report._dmarc.example.net Type: TXT Value: v=DMARC1
When using Suped, copy the reporting address provided for your domain and confirm external authorization resolves. The reporting domain can authorize multiple customer domains through a wildcard record. The authorization record belongs in the reporting domain's DNS.
If reports do not arrive, check the rua address, authorization record, and receiving mailbox. Reports commonly arrive daily rather than immediately after a test message. Gmail does not send ruf failure reports; use rua for aggregate reports, as described in Google's DMARC setup guidance.
Verify Gmail authentication and troubleshoot failures
Verify the message, not only the DNS. Send a new message from the custom Workspace address to an unrelated Gmail or Google Workspace recipient, then open More and Show original in the received message. A test sent to the same mailbox does not prove the external path.
- Read SPF: Confirm SPF shows PASS and inspect the authenticated return-path domain.
- Read DKIM: Confirm DKIM shows PASS and inspect the signing domain in the DKIM-Signature d= tag. It must match the From domain under your DMARC matching mode.
- Read DMARC: Confirm DMARC shows PASS. One matching SPF or DKIM pass is enough for DMARC.
- Check the source: Repeat the test through every application, relay, and delegated sending route.
Gmail Show original displaying SPF, DKIM, and DMARC PASS results
A test through the actual sending path exposes header rewriting, unexpected relays, DNS errors, and domain mismatch that a record-only lookup misses.
Use the test address supplied by the widget, send one representative message, then review its authentication diagnosis. Test plain Gmail sending and each third-party workflow separately because they can use different return paths and DKIM signatures.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If SPF fails, check for duplicate records, a missing Google include, lookup overflow, or an outbound gateway that sends through an unauthorized IP. If DKIM is absent, confirm Start authentication was selected and that the message was sent after activation. If DKIM fails, compare the selector (s=) and signing domain (d=) with the published key, and check whether an outbound gateway changed signed content.
If DMARC fails while SPF and DKIM pass, compare the domains shown in Authentication-Results with the visible From domain. With default relaxed matching, one passing method must share the From domain's organizational domain. With aspf=s or adkim=s, the corresponding domain must match exactly.
Common forwarding result
Forwarding often breaks SPF because the forwarder becomes the connecting server. A valid DKIM signature can preserve the DMARC pass if the message body and signed headers are not modified.
Monitor Google Workspace authentication changes
Authentication changes without a Gmail setting being touched. A new marketing sender, a removed DKIM public key, an SPF edit, or an outbound gateway change can create failures after a clean launch. Raw DMARC XML is useful evidence, but it needs continuous parsing and source classification to become operational.
- Monitor volume: Track pass rates by source, domain, method, and date so a regression is visible.
- Classify sources: Separate approved Google traffic from unknown services and unauthorized use.
- Alert on change: Notify an owner when failures rise, DNS records change, or a new source appears.
- Keep an owner: Assign each sending service to someone who can approve or remove it.
Suped is our DMARC reporting and email authentication platform. Its DMARC monitoring identifies sending sources and authentication failures in aggregate reports and provides alerts. Use it to review Google Workspace traffic and confirm other senders before changing policy.
A practical alerting baseline
- Failure threshold: Alert when the DMARC failure rate rises above the domain's normal range.
- New-source rule: Review every previously unseen sender before marking it approved.
- DNS rule: Escalate changes to SPF, DKIM, or DMARC records outside a planned window.
- Weekly review: Check authorized volume, unresolved sources, authentication regressions, and DNS changes.
Secure your domain with p=reject
Move to p=reject only after every legitimate sender has a stable DMARC pass. The goal is to reject unauthorized mail without interrupting invoices, support mail, user mail, or low-frequency business systems.
- Observe p=none: Collect enough DMARC data to see normal weekly and monthly senders.
- Verify every source: Fix SPF or DKIM domain matching for approved services and remove stale senders.
- Stage quarantine: Use p=quarantine for a domain whose legitimate senders pass, then review reports and delivery problems before moving to p=reject.
- Apply reject: Move to p=reject after the quarantine stage produces no legitimate delivery problems.
- Protect subdomains: Absent another applicable policy, subdomains inherit p when sp is omitted. Review separate subdomain records before setting sp=reject.
RFC 9989 marks pct as historic. Do not rely on pct to limit enforcement. Use explicit subdomain DMARC records to stage rollout separately, and verify the effective policy before each change.
DMARC enforcement stages
Move forward only when legitimate sources pass consistently at the current stage.
Monitor
p=none
Inventory senders and correct authentication.
Stage
p=quarantine
Request quarantine for DMARC failures.
Enforce
p=reject
Request rejection for DMARC failures.
Example full-enforcement DMARC recordDNS
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com
Use Suped's source reports to check whether a failure needs authentication work, removal, owner confirmation, or continued observation before raising enforcement.
Do not enforce by pass-rate alone
A 99% pass rate can still hide a critical monthly sender. Review the identity and business owner of every failing source, not only its volume, before publishing p=reject.
After reaching p=reject, keep the reports and alerts active. A reject policy requests rejection of mail that fails DMARC, but a future DNS edit or sender migration can still break legitimate authentication.
Gmail authentication FAQ
No. Google owns gmail.com DNS and handles authentication for personal Gmail accounts. These steps apply to a custom domain sending through Google Workspace.
Many changes appear within minutes, but Google states that SPF and DKIM DNS updates can take up to 48 hours. Separately, newly activated Gmail can need 24 to 72 hours before a DKIM key is available. Check DNS and send a new test message after activation.
Check the full DNS name and the selected domain. A provider that appends the domain needs google._domainkey rather than google._domainkey.example.com in its Host field. Use your actual selector if it differs from google. Confirm the complete TXT value is published, then select Start authentication and test a new message.
Passing authentication does not guarantee inbox placement. Review recipient complaints and message reputation, and verify required unsubscribe support. Sending servers also need TLS and valid forward and reverse DNS. Review the Gmail sender guidelines for the requirements beyond authentication.
No. DMARC passes when SPF or DKIM passes with a domain matching the visible From domain under the published matching mode. Gmail bulk-sender rules still require both SPF and DKIM, so verify that both pass even when one already produces a DMARC pass.
