Skip to main content
EN Deutsch Español Français Italiano Português

Google’s Email Sender Guidelines

Starting February 1, 2024, Google requires specific email authentication standards for sending messages to personal Gmail accounts. These standards are essential to avoid having emails marked as spam or blocked.

  • All Senders: Implement either SPF (Sender Policy Framework) or DKIM (DomainKeys Identified Mail)

  • Bulk Senders (any email sender that sends close to 5,000 or more messages per day): Implement SPF, DKIM, and DMARC (Domain-based Message Authentication, Reporting and Conformance)

The guidelines apply to all email senders, regardless of the email service provider you use, as long as you are sending emails to Gmail personal accounts (accounts ending in @gmail.com or @googlemail.com).

Note

For help with your domain sign-in information, settings, or TXT records, contact your domain provider.

Why Email Authentication Matters

Google's email authentication requirements enhance security and prevent malicious activities such as spoofing and phishing. By implementing these email authentication best practices, you improve the deliverability and reliability of your emails to Gmail accounts while protecting both your organization and recipients from impersonation and spam marking.

For optimal email delivery performance:

  1. Set up SPF: Ensure mail delivery and prevent spoofing by specifying authorized servers for your domain.

  2. Set up DKIM: Increase security for outgoing emails by adding encrypted digital signatures.

  3. Set up DMARC: Finally, enhance security for forged spam with DMARC. DMARC tells receiving servers what to do with emails that fail SPF or DKIM and provides reports on authentication activity.

Ensure that SPF, DKIM, and DMARC are configured for each of your sending domains through your domain provider. If you use an email service provider, verify they authenticate your domain's email with SPF and DKIM to avoid delivery issues.

Email Authentication Standards

Below are the key authentication methods you need to set up to comply with Google's requirements and enhance your email security:

  • SPF (Sender Policy Framework): SPF prevents email spoofing by specifying which mail servers are authorized to send email on behalf of your domain. It works by publishing a DNS record that lists these authorized servers. When an email is received, the recipient's mail server checks the SPF record to verify the sender. For setup instructions, see Set Up SPF TXT Records for your Domain.

  • DKIM (DomainKeys Identified Mail): DKIM ensures email authenticity and integrity by adding a digital signature to the email header. This is achieved using a pair of cryptographic keys—one private and one public. The private key is used to sign the email, and the public key, published in your domain’s DNS records, is used by the receiving server to verify the signature. For setup instructions, see Set Up DKIM TXT Records for your Domain.

  • DMARC (Domain-based Message Authentication, Reporting, and Conformance): DMARC builds on SPF and DKIM by providing instructions to receiving servers on how to handle emails that fail these checks. It publishes a policy in DNS that tells receiving mail servers what to do with emails that fail SPF or DKIM verification, such as rejecting or quarantining them. DMARC also provides a mechanism for receiving reports on email authentication activity which you can use to monitor email sent from your domain and identify senders that may be impersonating your domain. For setup instructions, see Set Up DMARC TXT Records for your Domain.

Set Up SPF TXT Records for Your Domain

Sender Policy Framework (SPF) is an email authentication protocol designed to prevent email spoofing and phishing attacks by specifying which mail servers are authorized to send emails on behalf of your domain. By setting up an SPF record, you help recipient servers verify that emails claiming to come from your domain are indeed sent from authorized servers. If an email is sent from an unauthorized server, it may be marked as spam or rejected.

Note

For help with your domain sign-in information, settings, or TXT records, contact your domain provider.

Before setting up SPF, ensure you have:

  • Domain Provider Access: Credentials for logging into your domain provider's management console. SPF is set up at your domain host provider, not in your Google Admin console.

  • (Optional) Existing SPF Record: Check if an SPF record is already set up.

  • Mail Server Information: A list of IP addresses or domains for all mail servers that send email on behalf of your domain.

To set up SPF:

  1. Sign-in to Your Domain Provider’s Management Console: Log in to the management console provided by your domain provider (e.g. GoDaddy). Locate the page or dashboard dedicated to updating DNS TXT records for your domain.

  2. Check Existing SPF Record: You might already have a TXT record set up for SPF with your domain provider. Verify if an SPF record already exists using the Google Admin Toolbox:

    • Enter your domain name and click Run Checks!.

    • After the test, click Effective SPF Address Ranges.

    • Review the results for existing SPF entries such as:

      • _spf.google.com

      • _netblocks.google.com followed by several IP addresses

      • _netblocks2.google.com followed by several IP addresses

      • _netblocks3.google.com followed by several IP addresses

        Note

        The results contain a summary contains flags showing if mail flow is:

        • working smoothly and no actions needed,

        • working but indicating issues that need to be addressed, or

        • needs to be set up.

  3. Define Your SPF Record: To define your SPF record, you need to create a TXT record. After you sign into your domain’s management console, find the page where you can update TXT records for your domain. Keep in mind, a single domain can have only one TXT record for SPF.

    • SPF Record: If you use Google Workspace only. If all email from your organization is sent using Google Workspace only, copy this line of text for your SPF record:

      v=spf1 include:_spf.google.com ~all

    • SPF Record: If you use Google Workspace plus other senders. If you send mail in other ways in addition to Google Workspace, you must create a custom TXT record for SPF to authorize these senders. Your SPF record should include a reference to Google Workspace, and to all servers that send email for your organization or domain. These might include services that send automatic emails, for example "Contact us" forms, and any third-party provider or service that sends email for your domain.

      To create a custom TXT record for your SPF record including reference to Google Workspace plus other senders you use:

      (Note that the IP addresses and domain names used in the following steps are examples. Replace them with IP addresses and domains for your senders. A normal record will have a mix of elements.)

      1. Start with the SPF record for Google Workplace:

        v=spf1 include:_spf.google.com ~all

      2. Add Authorized IP Addresses: List the single IP addresses (e.g., 198.51.100.1 and 2001:db8:1:1:1:1:1:1) or IP subnets (e.g., 198.51.100.0/24 and 2001:db8:1:1::/64) authorized to send emails. Use the ip4: tag for IPv4 addresses and the ip6: tag for IPv6 addresses. For example:

        v=spf1 ip4:198.51.100.0/24 ip6:2001:db8:1:1:1:1:1:1 include:_spf.google.com ~all

      3. Include Third-Party Services: If other services send emails on your behalf, use the include: tag to include another domain or sub-domain. For example:

        v=spf1 ip4:198.51.100.0/24 ip6:2001:db8:1:1:1:1:1:1 include:thirdpartydomain.com include:_spf.google.com ~all

      4. Specify Mail Servers: If other mail servers send emails on your behalf, use the a: tag. For example:

        v=spf1 a:mail.exampledomain.com ip4:198.51.100.0/24 ip6:2001:db8:1:1:1:1:1:1 include:thirdpartydomain.com include:_spf.google.com ~all

      5. Specify the Policy for Unauthorized Servers: End with ~all to define how emails from unauthorized servers should be treated. For example, as already specified by the SPF record used for Google Workspace:

        v=spf1 a:mail.exampledomain.com ip4:198.51.100.0/24 ip6:2001:db8:1:1:1:1:1:1 include:thirdpartydomain.com include:_spf.google.com ~all

      Starting with a soft fail (~all) is recommended to monitor and adjust your SPF record without disrupting email delivery, ensuring all legitimate email sources are correctly authorized before enforcing a strict hard fail (-all). Using ~all is typically effective, as it marks non-matching messages as spam.

      • ~all (soft fail): Emails from non-listed servers are accepted but marked as suspicious.

      • -all (hard fail): Emails from non-listed servers are rejected outright.

    Example SPF Record

    Description

    v=spf1 ip4:198.51.100.0/24 include:_spf.google.com ~all

    Authorizes emails from:

    • Servers with IP addresses between 198.51.100.0 and 198.51.100.255

    • Google Workspace

    This record allows email from a specific IPv4 address range and Google Workspace, marking non-listed sources as suspicious.

    v=spf1 ip4:198.51.100.0/24 include:_spf.google.com include:thirdpartydomain.com ~all

    Authorizes emails from:

    • Servers with IP addresses between 198.51.100.0 and 198.51.100.255

    • Google Workspace

    • Third-party email service Thirdpartydomain

    This record allows email from a specific IPv4 address range, Google Workspace, and an additional third-party service, marking non-listed as suspicious.

    v=spf1 ip6:2001:db8::/32 include:_spf.google.com ~all

    Authorizes emails from:

    • Servers with IP addresses between 2001:db8:0000:0000:0000:0000:0000:0000 and 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff

    • Google Workspace

    This record allows email from a wide IPv6 address range and Google Workspace, marking non-listed sources as suspicious.

    v=spf1 a:mail.exampledomain.com ip4:198.51.100.0/24 ip6:2001:db8::/32 include:_spf.google.com ~all

    Authorizes emails from:

    • Mail server mail.exampledomain.com

    • Servers with IP addresses between 198.51.100.0 and 198.51.100.255

    • Servers with IP addresses between 2001:db8:0000:0000:0000:0000:0000:0000 and 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff

    • Google Workspace

    This record covers both IPv4 and IPv6 ranges, Google Workspace, and a specific mail server, marking others as suspicious.

  4. Add SPF Record: To turn on SPF for your domain, add your SPF record in your domain provider's management console:

    1. Sign-in to Your Domain Provider’s Management Console: Log in to the management console provided by your domain provider. Locate the page or dashboard dedicated to updating DNS TXT records for your domain.

    2. Enter these values:

      Field Name

      Value to Enter

      Type

      TXT

      Host

      • For the root domain: @

      • When configuring an SPF record, use @ in the Host field for your root domain and consolidate all elements (e.g., include:, ip4:, ip6:, a:) into a single TXT record, as a domain can only have one SPF TXT record.

      Value

      • If you only use Google Workspace, enter: v=spf1 include:_spf.google.com ~all

      • • If you use additional email senders, enter the SPF record you created.

      Time To Live (TTL)

      1 hour or 3600 seconds
Troubleshoot SPF Issues

Note

For help with your domain sign-in information, settings, or TXT records, contact your domain provider.

If you've configured SPF (Sender Policy Framework) but are encountering issues such as failing SPF authentication, emails being rejected, or messages landing in spam folders, follow these troubleshooting steps:

  1. Verify SPF Record Setup

    • Check Existing SPF Record: Use a tool like MXToolbox or your domain’s DNS management interface to confirm that an SPF record exists for your domain.

    • Define and Add SPF Record: Ensure your SPF record is correctly formatted and includes all relevant mail servers. For example, an SPF record might look like v=spf1 ip4:192.168.0.1 include:_spf.example.com -all.

  2. Check SPF Authentication Results

    • Email Headers: In Gmail, open an email, click on the three dots in the upper-right corner, and select "Show original" to view SPF results under the "Authentication-Results" section.

    • Google Admin Toolbox: Copy the email headers and use the Google Admin Toolbox Messageheader tool to analyze SPF results.

  3. Ensure All Senders are Included in SPF Record

    • Review SPF Entries: Make sure all mail servers and services that send emails for your domain are included. This includes third-party email providers and website forms.

    • Update SPF Record: Add any missing IP addresses or domains to your SPF record. For example, if you use an email marketing service, ensure their sending IPs or include mechanisms are added to your record.

  4. Address Email Forwarding Issues

    • Check Forwarding Details: Use Email Log Search to verify if forwarded emails are failing SPF. Look for the original recipient’s address to confirm if forwarding is involved.

    • Contact Forwarding Service: Reach out to the third-party forwarding service to check if they can adjust their forwarding method or provide insights on SPF issues.

  5. Advanced SPF Troubleshooting

    • Analyze Message Headers: Look at the "Authentication-Results" section for SPF results like "softfail," "fail," or "neutral" and address based on the result. For instance:

      • No SPF Entry: Ensure your SPF record is correctly set up.

      • Softfail or Fail: Verify that all legitimate sending IPs are included in your SPF record.

      • TempError or PermError: Check for DNS issues or exceedance of the 10-lookup limit.

  6. Check DNS Lookups

    • Monitor Lookup Counts: SPF records are limited to 10 DNS lookups. So, your SPF TXT record can’t include more than 10 references to other domains. Each of these mechanisms, including nested lookups, in your SPF record results in a lookup: a, mx, include, ptr. Use tools like Google Admin Toolbox’s Check MX to monitor lookup counts and adjust your SPF record to avoid exceeding this limit.

Set Up DKIM TXT Records for Your Domain

DKIM, or DomainKeys Identified Mail, is an essential email authentication method that helps protect your domain from spoofing and prevents outgoing messages from being marked as spam. Spoofing is a deceptive email practice that falsifies the sender's address to appear as if it's from a legitimate organization or domain. DKIM plays a crucial role by detecting any unauthorized modifications to message content, including changes to the From address. Without DKIM, emails sent from your domain are more likely to be flagged as spam by receiving mail servers. To ensure your messages are delivered reliably, especially to Gmail users, it's recommended to set up DKIM along with SPF (Sender Policy Framework) authentication for your domain. This helps meet Google's email sender guidelines and enhances the authentication of your organization's emails.

Note

For help with your domain sign-in information, settings, or TXT records, contact your domain provider.

Before setting up DKIM, ensure you have:

  • Google Admin Access: Credentials for logging into your Google Admin console. You will get your DKIM key from your Google Admin console.

  • Domain Provider Access: Credentials for logging into your domain provider's management console. You will add the DKIM key information from your Google Admin console to your domain providers settings.

  • Outbound Gateways Settings Configured to Not Alter Emails after being Sent: Check your outbound email gateways settings do not interfere with the proper functioning of DKIM authentication for outgoing messages, as modifications such as adding footers or rewriting content after the message was sent can cause the email to fail DKIM verification.

    • Either set up the gateway so it doesn’t modify outgoing messages, or set up the gateway to change the message content first, then add the DKIM signature.

  • (Optional) Existing DKIM Key: Check for an existing DKIM key for your domain.

To set up DKIM:

  1. Sign-in to Your Google Admin Console: Access your Google Admin console. You must be signed in as a Super Administrator to get your DKIM key.

  2. Check Existing DKIM Key: If you’re already using a DKIM key for your domain, it could be with Google Workspace or with another email system.

    1. In the Google Admin console, go to Menu and select Apps, select Google Workspace, and click Gmail.

    2. Click Authenticate email and select the domain you want to check in the Selected domain menu.

    3. Locate the DNS host name (TXT record name) section:

      • If you've never set up DKIM in Google Workspace, this field will be empty.

      • If this field has a value, note the text preceding ._domainkey. This is your selector prefix.

    4. Navigate to the Google Admin Toolbox and enter your domain name in the Domain name field.

    5. Click the Run Checks! button and wait for the test to complete.

    6. After the test finishes, review which one of these messages is displayed:

      • DKIM authentication DNS setup: A DKIM key is set up for the domain and selector.

      • DKIM is not set up: No DKIM key exists for your domain with the entered prefix selector. To resolve this, set up a new key using the provided selector (the default selector is google).

  3. Generate DKIM Key:

    1. In the Google Admin console, go to Menu and select Apps, select Google Workspace, and click Gmail.

    2. Click Authenticate email and select the domain where you want to set up DKIM in the Selected domain menu.

    3. Click the Generate New Record button.

    4. Select your DKIM key settings:

      Setting

      Options

      DKIM key bit length

      2048. If your domain provider supports 2048-bit keys, select this option. Longer keys are more secure than shorter keys. 1024. If your domain host does not support 2048-bit keys, select this option.

      1024. If your domain host does not support 2048-bit keys, select this option.

      Prefix selector

      The default selector prefix is google. We recommend you use the default. But if your domain already uses a DKIM key with the prefix google, enter a different prefix.

    5. Click Generate and copy the DKIM values shown in the Authenticate email window:

      • DNS Host name (TXT record name)—This text is the name for the DKIM TXT record you will add to your domain provider’s DNS records.

      • TXT record value—This text is the DKIM key you will add to your DKIM TXT record.

  4. Add DKIM Key: Note that after adding a DKIM key, it can take up to 48 hours for DKIM authentication to start working.

    1. Sign-in to Your Domain Provider’s Management Console: Log in to the management console provided by your domain provider. Locate the page or dashboard dedicated to updating DNS TXT records for your domain.

    2. Add a New TXT Record for DKIM: Enter the following values, then save your changes.

      Field Name

      Value to Enter

      TXT record name (in the first field, under the DNS Host name)

      Enter the DNS Host name (TXT record name) shown in the Google Admin console.

      TXT record value (in the second field)

      Enter the TXT record value (DKIM key) shown in the Google Admin console.

  5. Turn On DKIM Signing: Note that the Authenticate email page in your Google Admin console might continue to display this message for up to 48 hours: ”You must update the DNS records for this domain. If you've correctly added your DKIM key at your domain provider, you can ignore the message.”

    1. In the Google Admin console, go to Menu and select Apps, select Google Workspace, and click Gmail.

    2. Click Authenticate email and select the domain where you want to set up DKIM in the Selected domain menu.

    3. Click the Start authentication button.

  6. Verify DKIM Authentication:

    1. Send an email message to someone who is using Gmail or Google Workspace. (You can't verify DKIM is on by sending yourself a test message.)

    2. Open the message in the recipient's inbox and find the entire message header. (Steps to view the message header differ for different email applications. To show message headers in Gmail, next to Reply, click More Show original.)

    3. In the message header, look for Authentication-Results. Receiving services use different formats for incoming message headers, however the DKIM results should say something like DKIM=pass or DKIM=OK. If the message header doesn't include a line about DKIM, messages sent from your domain are not being signed with DKIM.

Troubleshoot DKIM Issues

Note

For help with your domain sign-in information, settings, or TXT records, contact your domain provider.

If emails from your domain are not passing DKIM authentication or are being rejected or marked as spam, follow these steps to troubleshoot and resolve DKIM issues:

  1. Verify DKIM Setup

    1. Obtain DKIM Key: In your Admin console, obtain the DKIM key required for your domain.

    2. Add DKIM Key: Add the DKIM key as a TXT record in your domain provider’s DNS settings. Ensure the key is correctly entered and complete.

    3. Activate DKIM: In the Admin console, enable DKIM signing for your domain.

  2. Check DKIM Authentication Results

    1. Verify Messages: Send a test email to a personal email account (e.g., Gmail) to rule out issues with specific receiving servers.

    2. Review Email Headers: In Gmail, click on "Show original" to view DKIM status under the "Authentication-Results" header.

    3. Use Google Admin Toolbox: Analyze message headers with the Google Admin Toolbox Messageheader tool to check DKIM results.

  3. Confirm DKIM Key Integrity

    1. Check DKIM TXT Record: Ensure that your DKIM TXT record is not truncated and is correctly formatted. DKIM keys larger than 255 characters may be split into multiple TXT records.

    2. Compare Records: Use the Google Admin Toolbox Dig tool to verify that the TXT record value matches the key in your Admin console. Enter your DKIM record (e.g., google._domainkey) followed by your domain to compare results.

  4. Address Message Forwarding Issues

    1. Check for Modifications: Inspect the "Authentication-Results" header for any "body hash did not verify" messages, indicating that the email was altered during forwarding.

    2. Outbound Gateways: Ensure that outbound gateways do not modify the content of outgoing messages, as this can cause DKIM failures.

    3. Verify Forwarding: Use Email Log Search to check if forwarded messages are the cause of DKIM issues. Contact the forwarding service if necessary.

  5. Contact Admins for Rejected DKIM-Signed Messages

    1. Reach Out: If DKIM is correctly set up but messages are still rejected or sent to spam, contact the administrator of the rejecting email server for further assistance.

  6. Check TXT Record Character Limits

    • Review Limits: Ensure your DKIM TXT records adhere to your domain provider’s character limits. Most TXT records can have up to 255 characters. For TXT records that include more than 255 characters, DNS adds multiple strings together in a single record.

      If you’re using a 2048-bit DKIM key, you can’t enter it as a single text string in a DNS record with a 255-character limit. Instead, take these steps:

      1. Split the key characters into multiple text strings.

      2. Put each string inside quotes.

      3. Enter the strings one after another in the TXT record Value field at your domain provider.

Set Up DMARC TXT Records for your Domain

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an email authentication protocol that builds on top of SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to prevent email spoofing and phishing attacks. With DMARC, domain owners can instruct receiving mail servers on how to handle emails that fail SPF and DKIM checks.

The key components of DMARC are:

  • Policy (p): Specifies the action to be taken when an email fails authentication checks. The policy options are none (monitor only), quarantine (mark as spam), or reject (do not deliver).

  • Reporting (rua=mailto:): Specifies where DMARC reports should be sent. These reports provide detailed information about emails that pass and fail authentication checks.

Before setting up DMARC, ensure you have:

  • Domain Provider Access: Credentials for logging into your domain provider's management console. DMARC is enabled at your domain host provider, not in your Google Admin console.

  • SPF and DKIM Already Set Up: Before implementing DMARC, ensure that Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) are activated for your domain. This authentication is essential for DMARC functionality as DMARC tells receiving mail servers what to do when they get a message that appears to be from your organization, but the message does not pass SPF and/or DKIM email authentication checks.

    Warning

    • If you don't set up SPF and DKIM before enabling DMARC, messages sent from your domain will likely experience delivery issues.

    • Allow 48 hours after setting up SPF and DKIM before setting up DMARC.

  • (Optional) Existing DMARC Record: Check for an existing DMARC record for your domain.

  • Third-Party Mail Authentication: Ensure that messages sent by third-party providers are authenticated to comply with DMARC policies. To enhance authentication for messages sent by third-party providers:

    • Confirm with your third-party provider that DKIM is correctly configured.

    • Ensure that the envelope sender domain used by the provider matches your domain.

    • Add the IP addresses of the provider's sending mail servers to the SPF record for your domain.

Set Up DMARC

To set up DMARC:

  1. Sign-in to Your Domain Provider’s Management Console: Access your domain provider's platform and navigate to the DNS TXT records management section.

  2. Check Existing DMARC Record: Prior to DMARC setup, verify if your domain already has a DMARC DNS TXT record. If present, review DMARC reports to confirm successful message authentication and delivery. To check at your domain provider for a TXT record for DMARC:

    1. Log in to the management console provided by your domain provider.

    2. Locate the page or dashboard dedicated to updating DNS TXT records for your domain.

    3. Review the DNS TXT records associated with your domain. If a DMARC record exists, it will typically begin with v=DMARC.

  3. Define Your DMARC Record: To define your DMARC record, you need to create a TXT record which defines how strictly DMARC should check messages and the recommended actions for receiving servers.

    As you begin implementing DMARC, we suggest starting with a relaxed enforcement policy set to "none." As you gain insights into how messages from your domain are authenticated by receiving servers, gradually adjust your policy from “none” to "quarantine" and ultimately to "reject."

    The DMARC record is in the form of a line of plain text consisting of a list of DMARC tags values, separated by semicolons. Some tags are required and some are optional. Example: v=DMARC1; p=reject; rua=mailto:mailbox@example.com, mailto:dmarc@example.com; pct=10; adkim=r; aspf=r

    Tag

    Required?

    Description

    Values

    v

    Requ

    Specifies the DMARC version.

    Must be DMARC1.

    p

    Required

    Instructs the receiving mail server on actions for messages that fail authentication.

    none — Take no action, deliver the message, and log it. Reports are sent to the email address specified in the rua tag.

    quarantine — Mark the message as spam and send it to the spam folder. Recipients can review it for legitimacy.

    reject — Reject the message and usually send a bounce message to the sender.

    pct

    Required

    Defines the percentage of messages subjected to the DMARC policy.

    Must be a whole number from 1 to 100. If not specified, the policy applies to 100% of messages.

    rua

    Optional

    Get DMARC reports sent to an email address. The email address must include mailto:.

    To send DMARC reports to multiple emails, separate each email address with a comma and add the mailto: prefix before each address.

    Example: mailto:dmarc-reports@example.com, mailto:dmarc-admin@example.com (replace example.com with your domain).

    sp

    Optional

    Sets the policy for subdomains of your primary domain.

    none — Take no action, deliver the message, and log it. Reports are sent to the email address specified in the rua tag.

    quarantine — Mark the message as spam and send it to the spam folder. Recipients can review it for legitimacy.

    reject — Reject the message and usually send a bounce message to the sender.

    If not specified, subdomains inherit the parent domain’s policy.

    adkim

    Optional

    Specifies the alignment policy for DKIM, indicating how strictly the sender domain must match the d=domainname in DKIM signatures.

    s—Strict alignment. The sender domain name must exactly match the corresponding d=domainname in the DKIM mail headers.

    r—Relaxed alignment (default). Allows partial matches. Any valid subdomain of d=domain in the DKIM mail headers is accepted

    adspf

    Optional

    Specifies the alignment policy for SPF, indicating how strictly the sender domain must match the domain in the SMTP MAIL FROM command.

    s—Strict alignment. The sender domain must exactly match the domain in the SMTP MAIL FROM command.

    r—Relaxed alignment (default). Allows partial matches. Any valid subdomain of domain name is accepted.

  4. Add DMARC Record: Note that DKIM and SPF should be authenticating messages for at least 48 hours before turning on DMARC.

    1. Sign-in to Your Domain Provider’s Management Console: Log in to the management console provided by your domain provider. Locate the page or dashboard dedicated to updating DNS TXT records for your domain.

    2. Add a New TXT Record for DMARC. Enter the following values, then save your changes.

      Field Name

      Value to Enter

      TXT record name (in the first field, under the DNS Host name)

      Enter _dmarc.exampledomain.com (replace exampledomain.com with your domain)

      TXT record value (in the second field)

      Enter your DMARC policy text.

      For example, enter v=DMARC1; p=none; rua=mailto:dmarc-reports@exampledomain.com (replace exampledomain.com with your domain).

  5. Extend to Subdomains and Additional Domains (if applicable). If you have multiple domains or subdomains, each domain so each domain can have a different policy, and different report options (defined in the record). To define a DMARC policy for subdomains, use the sp policy tag in the DMARC record for the parent domain. If you don’t create DMARC policies for subdomains, they inherit the parent domain’s DMARC policy.

Monitor DMARC Reports

Regularly monitor reports about DMARC activity for your domain. These reports, sent to the email address specified in the DMARC policy (rua tag), provide insights into email server activity. Adjust your DMARC policy as needed based on these reports.

Review the reports to find out:

  • What servers or third-party senders are sending mail for your domain

  • What percent of messages from your domain pass DMARC

Look for any problem trends, such as:

  • Valid messages being marked as spam

  • Bounce or error messages from recipients

Quarantine a Small Percentage of Messages

Initially, start with a relaxed DMARC policy with enforcement set to none. This lets you start getting reports without risking messages from your domain being rejected or marked as spam by receiving servers. After observing DMARC reports for at least a week, adjust your policy to “quarantine” and add the pct tag to apply the policy to a small percent of your mail.

To quarantine a small percentage of messages:

  1. Log in to the management console provided by your domain hosting provider to update the DMARC DNS TXT record.

  2. Add a policy that affects a small percentage of messages and enforces quarantine. For example, a policy that applies to only 5% of incoming emails and directs messages failing DMARC checks to recipients’ spam folders:

    v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc-reports@exampledomain.com

Tip

Large organizations should gradually increase the percentage of affected messages to minimize the risk of rejections or spam markings. For instance, a small organization might start with quarantining 10%, while a larger enterprise might begin with 1%.

Troubleshoot DMARC Issues

If emails from your domain are failing DMARC authentication, being rejected by receiving servers, or landing in recipients' spam folders, follow these steps to troubleshoot and resolve DMARC issues:

  1. Verify DMARC Record

    • Check Configuration: Ensure your DMARC record is properly configured. Verify that the DMARC record is correctly set up with your domain provider and is present in your DNS settings.

  2. Ensure SPF and DKIM are Enabled

    • Enable SPF and DKIM: Confirm that SPF and DKIM are enabled and correctly configured for your domain. Both should be active for at least 48 hours before enabling DMARC.

    • Detailed Setup: Follow the setup instructions for SPF and DKIM to ensure they are correctly implemented.

  3. Check Authentication Results

    • Review Headers: Inspect email headers to verify SPF, DKIM, and DMARC results. In Gmail, click "Show original" to view these results.

    • Use Diagnostic Tools: Input message headers into the Google Admin Toolbox Messageheader tool to check authentication statuses.

  4. Check DMARC Reports

    • Check Reports: Check your DMARC reports to ensure messages pass SPF, DKIM, and DMARC checks. You can use a DMARC report analysis tool or service for comprehensive insights.

  5. Address DMARC Failures

    • Resolve Failures: If outgoing messages fail DMARC, check your SPF and DKIM settings. Ensure messages pass at least one of these checks to comply with DMARC policies.

    • Review DMARC Policy: Verify your DMARC policy and alignment settings. A strict policy may lead to increased rejection rates or spam placement.

    • Check Daily Reports: Examine DMARC daily reports to identify which outgoing messages do not pass SPF, DKIM, or DMARC.

  6. Evaluate Mail Sending Practices

    • Follow Best Practices: Ensure compliance with best practices for sending emails, particularly if you send large volumes. Refer to guidelines for sending email to Gmail users.

  7. Use Email Log Search for Insights

    • Detailed Search: Utilize Email Log Search for detailed information on specific messages sent through Google Workspace. Search by Sender IP address and review message details to diagnose issues.

Was this article helpful?

Return to top