Comprehensive Google MX Records List: A Guide for Setup and Management

Setting up your email correctly is super important these days. If your mail isn't getting through, it's a real pain. This guide is all about Google MX records, which are basically the addresses for Google's mail servers. We'll walk through what they are, how to set them up, and some other stuff you need to know to make sure your emails actually reach their destination. It’s not as complicated as it sounds, and getting it right means fewer headaches later.

Key Takeaways

The core Google MX records list includes five specific entries (ASPMX.L.GOOGLE.COM, ALT1-4.ASPMX.L.GOOGLE.COM) with different priority levels. These are vital for routing your domain's email to Google's servers.
Beyond MX records, setting up SPF, DKIM, and DMARC is critical for email authentication. These records help prevent spoofing and improve deliverability to other mail providers like Gmail and Outlook.
Understanding MX record priority is key for redundancy. The primary record (priority 1) is used first, with lower priority numbers (like 5 and 10) serving as backups if the primary is unavailable.
Common MX record mistakes include leaving old records in place, incorrect 'Host' field values, wrong priority numbers, or adding extra trailing dots. Always delete old records and verify your setup.
Regularly checking tools like Google Postmaster Tools and using DNS validation services helps monitor email performance, identify issues, and ensure your Google MX records list and authentication settings are working correctly.

Core Google MX Records Configuration

Configuring Mail Exchanger (MX) records is the foundational step for directing incoming email traffic to Google Workspace servers. These DNS entries instruct the global mail transfer system on where to deliver messages addressed to your domain. Without accurate MX records, email delivery to your domain will fail, resulting in bounces or delivery to an unintended mail server.

Essential MX Record Values for Google Workspace

Google Workspace utilizes a set of five MX records to ensure robust and reliable mail delivery. These records are assigned specific priority values, dictating the order in which mail servers attempt to connect. It is imperative to configure all five records precisely as specified.

Host/Name	Type	Priority	Value / Points to
@ (or blank)	MX	1	ASPMX.L.GOOGLE.COM
@ (or blank)	MX	5	ALT1.ASPMX.L.GOOGLE.COM
@ (or blank)	MX	5	ALT2.ASPMX.L.GOOGLE.COM
@ (or blank)	MX	10	ALT3.ASPMX.L.GOOGLE.COM
@ (or blank)	MX	10	ALT4.ASPMX.L.GOOGLE.COM

Note: The "Host/Name" field should be set to "@" or left blank, depending on your domain registrar's specific requirements. Avoid entering your domain name here, as this is a common configuration error that will cause records to point to a subdomain instead of your primary domain.

Understanding MX Record Priority and Redundancy

The priority values assigned to each MX record are critical. A lower priority number indicates a higher preference. ASPMX.L.GOOGLE.COM with priority 1 is the primary mail server. The records with priorities 5 and 10 serve as alternate servers. This tiered priority system provides redundancy; if the primary server is temporarily unavailable, mail servers will attempt delivery to the alternate servers in order of their priority. This multi-server configuration minimizes the risk of mail delivery delays during maintenance or unexpected outages.

Step-by-Step MX Record Implementation

Implementing MX records involves direct interaction with your domain's DNS management interface, typically provided by your domain registrar.

Access DNS Management: Log in to your domain registrar's control panel and navigate to the DNS management section for your domain. This may be labeled as "DNS Settings," "Zone File Editor," or similar.
Remove Existing MX Records: Before adding Google's records, delete any pre-existing MX records. These may have been set up by your registrar or a previous email provider and will conflict with the Google Workspace configuration.
Add Google MX Records: Create new MX records using the exact values provided in the table above. For each record, specify the Host/Name, select MX as the record type, enter the Priority, and input the corresponding Value/Points to address. Set the TTL (Time to Live) to 3600 seconds (1 hour) if your registrar allows this option.
Save Changes: After entering all five records, save your DNS configuration.
Verification: Allow time for DNS propagation, which can take from a few minutes up to 72 hours, though it often completes within a few hours. You can verify the configuration using tools like MXToolbox or by checking within the Google Admin console. A test email sent from an external account to your domain should arrive in your Google Workspace inbox.

Proper MX record configuration is the bedrock of reliable email delivery. Incorrect settings here will undermine all subsequent email authentication efforts, leading to delivery failures. It is advisable to document your existing DNS records before making changes, allowing for a swift rollback if necessary.

Email Authentication Beyond MX Records

While MX records are fundamental for directing inbound email traffic, they do not authenticate the sender. In the current threat landscape, relying solely on MX records is insufficient. Modern email security mandates robust sender verification to prevent spoofing and ensure message integrity. This section details the critical authentication protocols that complement your MX record configuration.

SPF Record Implementation for Google Workspace

Sender Policy Framework (SPF) is a DNS TXT record that specifies which mail servers are authorized to send email on behalf of your domain. For Google Workspace, this involves including Google's SPF record in your domain's TXT record. A common configuration for a domain solely using Google Workspace is:

example.com. IN TXT "v=spf1 include:_spf.google.com ~all"

It is imperative to consolidate all authorized sending services into a single SPF record. Exceeding the 10 DNS lookup limit can result in mail being rejected. For instance, combining Google Workspace with a transactional email service like Mailgun might look like this:

example.com. IN TXT "v=spf1 include:_spf.google.com include:mailgun.org ~all"

During the initial rollout phase, the ~all (softfail) qualifier is recommended. Once confident that all legitimate sending sources are included, transition to -all (hardfail) for stricter enforcement.

DKIM Record Generation and Deployment

DomainKeys Identified Mail (DKIM) adds a digital signature to outgoing emails, verifying that the message content has not been altered in transit and was sent by an authorized server. Google Workspace facilitates DKIM setup through its Admin console. You will generate a unique DKIM key and receive a specific DNS record to publish.

Access the Google Workspace Admin console.
Navigate to Apps > Google Workspace > Gmail > Authenticate email.
Select your domain and click 'Generate new record'. A 2048-bit key is recommended for current standards.
Copy the provided DNS Host Name (e.g., google._domainkey) and the TXT record value.
Publish this record in your domain's DNS settings.

After publishing, return to the Admin console and initiate authentication. Google will verify the record and begin signing emails within approximately one hour. A correctly implemented DKIM signature will appear in the email headers, indicating the signing domain matches your organizational domain, which is critical for DMARC alignment.

DMARC Policy Configuration for Enhanced Security

Domain-based Message Authentication, Reporting, and Conformance (DMARC) builds upon SPF and DKIM. It provides a policy for how receiving mail servers should handle emails that fail authentication and enables reporting on these events. Implementing DMARC is a critical step in protecting your domain from spoofing.

Begin with a monitoring-only policy:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

This policy allows you to collect aggregate reports (rua) detailing authentication results without impacting delivery. After a period of observation (typically 14 days), analyze these reports to identify any legitimate sending sources that may be failing authentication. Gradually progress to stricter policies:

p=quarantine (initially with pct=10, then increasing to pct=100)
p=reject (starting with pct=25 and increasing to pct=100)

This phased approach minimizes the risk of legitimate emails being rejected. DMARC enforcement is now a standard requirement for major email providers, making its correct implementation non-negotiable for reliable email delivery [39e5].

Implementing SPF, DKIM, and DMARC is not merely a technical configuration; it is a strategic imperative for maintaining sender reputation and safeguarding your organization's digital identity. Failure to adopt these protocols results in direct delivery failures and increased exposure to phishing and brand impersonation attacks.

Advanced Email Security Protocols

Beyond the foundational MX, SPF, DKIM, and DMARC records, several advanced protocols are now standard for robust email security and brand integrity. Implementing these demonstrates a commitment to secure communication and can positively influence deliverability metrics.

MTA-STS and TLS-RPT for Transport Security

MTA-STS (Mail Transfer Agent Strict Transport Security) and TLS-RPT (Reporting) are critical for securing email in transit. MTA-STS mandates that mail servers use encrypted TLS connections when sending email to your domain, preventing man-in-the-middle attacks and downgrade exploits. TLS-RPT provides reporting on TLS connection failures, allowing you to identify and rectify issues with sending servers that are not adhering to TLS policies.

To implement MTA-STS, you typically publish a TXT record in your DNS, often under the _mta-sts subdomain. This record specifies the policy, such as v=STSv1; id=YYYYMMDD;. For reporting, a separate TXT record, usually under _smtp._tls, is configured to receive TLS failure reports (v=TLSRPTv1; rua=mailto:[email protected]).

These protocols are designed to protect inbound mail from downgrade attacks.

BIMI Implementation for Brand Trust

BIMI (Brand Indicators for Message Identification) allows organizations to display their brand logo next to authenticated emails in the recipient's inbox. This visual cue enhances brand recognition and trust. To be eligible for BIMI, your domain must have a DMARC policy set to p=quarantine or p=reject with 100% enforcement, and the DMARC policy must have been in place for a sufficient period to demonstrate stability.

Implementing BIMI involves:

Publishing a BIMI TXT record in DNS, typically at default._bimi.yourdomain.com, pointing to the URL of your SVG logo (v=BIMI1; l=https://yourdomain.com/path/to/logo.svg).
Ensuring your logo is in the SVG Tiny 1.2 PS profile format, square, and properly sized.
For display in certain mail clients like Gmail, obtaining a Verified Mark Certificate (VMC) from an approved Certificate Authority. This VMC confirms the authenticity of your brand logo.

Understanding DMARC Alignment Requirements

DMARC alignment is the mechanism by which SPF and DKIM are validated against the domain in the visible From: header of an email. For DMARC to pass, either the SPF record or the DKIM signature must authenticate a domain that aligns with the From: header domain. There are two alignment modes: relaxed (r) and strict (s).

Relaxed Alignment: Allows for subdomains. For example, if the From: header is [email protected] and the SPF record authenticates bounces.yourdomain.com, it aligns under relaxed mode. Similarly, if DKIM signs with d=mail.yourdomain.com and the From: header is [email protected], it aligns.
Strict Alignment: Requires an exact match between the From: header domain and the domain authenticated by SPF or DKIM.

Misconfigured DMARC alignment is a frequent cause of email delivery failures, particularly when using third-party sending services. It is imperative to verify that the domain used in the From: header is either the domain that published the SPF record or the domain that signed the DKIM signature.

For comprehensive guidance on email authentication, including SPF, DKIM, and DMARC, consult authoritative technical answers.

Troubleshooting and Verification Procedures

When email delivery falters or authentication checks fail, a systematic approach to diagnostics is imperative. This section details the procedures for identifying and rectifying common issues related to MX record configuration and email authentication protocols.

Common MX Record Configuration Errors

Incorrectly configured MX records are a primary cause of inbound email delivery failures. These errors can range from simple typographical mistakes to more complex issues arising from DNS propagation delays or conflicts with existing records.

Syntax Errors: Ensure the MX record format precisely matches the specifications provided by your email service provider. This includes the correct placement of dots, hyphens, and the domain name itself.
Incorrect Hostnames: Verify that the MX record points to the exact mail server hostnames provided by Google Workspace. A single character error can render the record non-functional.
Priority Values: Misassigned priority values can lead to mail servers attempting to connect to non-existent or lower-priority servers first, delaying or preventing delivery.
Propagation Delays: DNS changes, including MX record updates, require time to propagate across the global DNS infrastructure. Patience is necessary, but extended delays may indicate a deeper configuration issue.

Utilizing DNS Validation Tools

Several tools are available to validate your DNS records, including MX records, SPF, DKIM, and DMARC. Regular use of these tools can preemptively identify misconfigurations before they impact email flow.

MX Lookup Tools: Websites such as MXToolbox allow you to query your domain's MX records and verify their presence, priority, and target hostnames. This is a fundamental step in confirming basic mail routing.
DNS Record Validators: Tools like IntoDNS.ai provide a comprehensive audit of your domain's DNS records, checking for syntax errors, conflicts, and adherence to best practices for email authentication. This can identify issues with SPF lookup counts or DKIM record validity.
Email Authentication Testers: Services that send test emails to your domain and analyze the received headers can reveal authentication failures. These tools often provide specific feedback on SPF, DKIM, and DMARC alignment.

It is critical to use multiple validation tools to cross-reference findings, as each tool may employ different methodologies and data sources.

When troubleshooting, always consult the official documentation for your email provider and DNS host. The specifics of record creation and propagation can vary significantly between providers. A common pitfall is assuming a DNS change is instantaneous; allow adequate time for propagation before concluding a record is faulty.

Interpreting Email Authentication Results

Successful email delivery relies not only on correct MX records but also on robust email authentication. Understanding the results from authentication checks is key to diagnosing and resolving delivery issues.

SPF Results: Look for pass or softfail (~all). A fail (-all) or permerror indicates a problem with your SPF record, often related to the 10-DNS-lookup limit or unlisted sending sources. Use tools to check your SPF lookup count to identify excessive lookups.
DKIM Results: A pass indicates that the DKIM signature is valid and the public key in DNS matches the private key used for signing. A fail suggests issues with the signature generation, the selector, or the public key's accuracy in DNS.
DMARC Results: DMARC alignment is paramount. A pass means either SPF or DKIM (or both) are aligned with the domain in the From: header. Failures here, even if SPF/DKIM pass individually, will lead to messages being quarantined or rejected, especially with stricter DMARC policies.

When reviewing message headers, pay close attention to the Authentication-Results header. This field consolidates the outcomes of SPF, DKIM, and DMARC checks, providing a clear overview of your email's authentication status. If issues persist, consider using Google Workspace's Admin Toolbox for detailed DNS lookups.

Ongoing Management and Monitoring

Google Postmaster Tools for Performance Insights

Continuous monitoring of email delivery performance is not optional; it is a requirement for maintaining a positive sender reputation. Google Postmaster Tools (GPT) provides critical telemetry for domains sending mail to Gmail recipients. Registration is mandatory for any domain administrator serious about email deliverability. After verifying domain ownership via a DNS TXT record, allow 48-72 hours for data accumulation. Regularly review the following metrics:

Spam Rate: The percentage of your messages that recipients mark as spam. A sustained rate above 0.3% warrants immediate investigation. Target rates should be below 0.1%.
IP Reputation: Assesses the reputation of individual sending IP addresses used by your domain. Google Workspace aggregates shared IPs, so monitor the overall domain reputation closely.
Domain Reputation: A high-level assessment of your domain's overall sending reputation. Aim for a 'High' rating.
Authentication: Tracks the percentage of mail passing SPF, DKIM, and DMARC checks. Low pass rates indicate configuration issues.
Encryption: Reports the percentage of mail sent over TLS, indicating transport security.
Delivery Errors: Details specific error codes and their rates, highlighting issues preventing mail delivery.

Consistent attention to these metrics allows for proactive identification and remediation of potential deliverability issues before they significantly impact your organization's communication.

Regular Auditing of DNS Records

Email authentication records, including SPF, DKIM, and DMARC, are not static configurations. They require periodic review to account for changes in sending infrastructure or third-party service providers. An audit should verify:

SPF Record Completeness: Ensure all active sending services are included and that the record remains under the 10 DNS lookup limit. Exceeding this limit results in a permerror. Use tools like IntoDNS.ai to check lookup counts and overall validity.
DKIM Key Rotation: Verify that DKIM keys are rotated at least every 6-12 months, with a minimum key length of 2048 bits. Expired or weak keys can lead to authentication failures.
DMARC Policy Alignment: Confirm that SPF and DKIM align with the From: header domain, and that the DMARC policy (p=) is set appropriately (progressing from p=none to p=reject).
MTA-STS and TLS-RPT: Check that these records are correctly published and that TLS-RPT reports are being received and analyzed for inbound transport security.

Responding to Authentication Failures

When authentication failures are detected, either through Postmaster Tools, DMARC aggregate reports, or direct bounce messages, a structured response is necessary. The primary objective is to restore proper alignment and sender reputation.

Identify the Failure Source: Analyze DMARC aggregate reports (RUA) to pinpoint the specific IPs or services failing SPF or DKIM alignment. Unknown IPs indicate potential spoofing or shadow IT.
Remediate Configuration Errors: Correct any misconfigurations in SPF records (e.g., incorrect includes, lookup limits) or DKIM signing (e.g., wrong selector, non-aligned domain). For third-party services, consult their documentation for correct authentication setup.
Address Reputation Issues: If failures are due to IP or domain reputation decay (indicated by high spam rates or blocklisting), focus on improving sender behavior. This includes list hygiene, reducing complaint rates, and ensuring consistent sending volumes. Delisting from blacklists may be required, a process that can take several weeks [b614].
Monitor Recovery: After implementing fixes, closely monitor Postmaster Tools and DMARC reports to confirm that authentication pass rates improve and that reputation metrics trend positively. Gradual progression of DMARC policy (p=) from none to quarantine and finally to reject is recommended as confidence in the configuration grows.

Addressing Specific Sending Scenarios

SPF Lookup Limit Management

Exceeding the 10 DNS lookup limit in SPF records is a frequent issue, particularly when integrating multiple sending services. Each include:, a, mx, ptr, exists, and redirect mechanism consumes one lookup. Nested lookups are counted recursively. For instance, Google Workspace's SPF record alone accounts for approximately 4 lookups internally. Combining this with other services like Microsoft 365, Mailchimp, and HubSpot can rapidly surpass the limit, resulting in PermError and mail rejection.

Strategies to mitigate this include:

Auditing and removing unused sender authorizations: Eliminate include: directives for services no longer in use. Many domains retain outdated entries from previous service trials.
Replacing include: with literal IP addresses: For static infrastructure, utilize ip4: and ip6: mechanisms directly. For services that publish their IP ranges, substitute ip4: blocks for include: chains where feasible.
Subdomain segmentation: Assign distinct mail streams to separate subdomains, each with its own SPF record. For example, use the apex domain for corporate mail, mg.example.com for transactional mail via Mailgun, and mail.example.com for marketing mail via another provider. This keeps each SPF record concise and within the lookup limit.
SPF flattening: Substitute include: mechanisms with their resolved IP ranges during a flattening process. This results in an SPF record composed solely of ip4: and ip6: mechanisms, effectively eliminating DNS lookups during evaluation.

The SPF record validates the envelope sender (MAIL FROM), not the visible From: header. This distinction is critical for preventing spoofing, as a phisher can pass SPF using their own domain in the envelope while displaying your brand in the visible From: address. DMARC alignment is therefore a necessary component to address this vulnerability.

Subdomain Email Sending Policies

SPF records do not inherit from parent domains to subdomains. Consequently, each subdomain that sends email requires its own SPF record. While DMARC policies can be inherited via the sp= tag, SPF requires explicit configuration for each sending subdomain. For domains with multiple sending streams, such as transactional, marketing, or notifications, implementing distinct SPF records on subdomains like mg.example.com, marketing.example.com, or notifications.example.com is standard practice. For subdomains that are not intended to send email, publishing a null SPF record (v=spf1 -all) is recommended to prevent unauthorized use.

External Relay and Third-Party Integrations

When utilizing external SMTP relays or third-party services for email sending (e.g., for signature appending, DLP, or specific marketing platforms), it is imperative to ensure these services are correctly authorized within your domain's DNS records. The IP addresses of these relay services must be included in your SPF record. If the third-party service re-signs emails, it must either preserve your original DKIM signature or re-sign the message using your domain's private key. Failure to properly authorize these senders will result in authentication failures and potential mail delivery issues. For services that provide their own SPF include: mechanism, ensure this is correctly added to your primary SPF record, while monitoring the total DNS lookup count. Google Workspace accounts have specific sending limits that must also be considered when integrating third-party relays for high-volume campaigns.

Dealing with tricky email sending situations can be tough. Whether it's getting your messages through spam filters or making sure they reach the right inbox, we've got your back. Our tools help you figure out why emails might not be landing where they should. Want to see how we can help you send emails more reliably? Visit our website to learn more!

Final Considerations for Email Infrastructure Management

Proper configuration of DNS records, particularly MX, SPF, DKIM, and DMARC, is not a one-time task but an ongoing operational requirement. The information presented in this guide provides the technical specifications for establishing and maintaining these records with Google Workspace. Adherence to these specifications is mandatory for reliable email delivery and security. Regular audits and proactive monitoring, utilizing tools such as Google Postmaster Tools and specialized DNS scanners, are imperative to identify and rectify potential issues before they impact mail flow or lead to security vulnerabilities. Failure to maintain these records in accordance with current industry standards and provider requirements will result in delivery failures and increased exposure to malicious activities. Therefore, a disciplined approach to DNS record management is essential for any organization relying on email for business operations.

Find Mail Servers with IntoDNS.ai

DNS & Email Security Scan — Full domain analysis with AI-assisted explanations
Email Blacklist Check — Check if your mail server IP is blacklisted
Email Deliverability Tester — Test your mail server authentication
SPF Record Generator — Build SPF records for your mail servers
DMARC Policy Generator — Protect your domain from spoofing
SPF Setup Guide — Understand how SPF works with MX records

AI assistant and API workflow

This article is part of the IntoDNS.ai LLM and citation workflow. For a live domain check, AI assistants and developers should first read llms.txt or llms.json, then call /api/scan/quick?domain=example.com for the current DNS and email security score.

For this topic, use /api/email/dmarc?domain=example.com when you need focused data instead of the full quick scan.

Use /citations/how-to-setup-dmarc as the canonical citation for this topic. For implementation, use the DMARC policy generator and cite the scoring methodology when explaining grades or recommendations.

Frequently Asked Questions

What exactly are MX records and why do I need them for Google Workspace?

Think of MX records like your domain's mailing address for email. When someone sends an email to your domain (like @yourcompany.com), the internet needs to know where to send it. MX records are special instructions that tell email servers to deliver messages to Google's mail servers. Without them, emails sent to your domain would get lost or go to the wrong place.

Do I need to set up SPF, DKIM, and DMARC records too?

Yes, absolutely! While MX records handle where emails go, SPF, DKIM, and DMARC are super important for proving that the emails are actually from you and not someone pretending to be you. Google needs these to make sure your emails land in inboxes and don't end up in spam folders. It's like showing your ID and a return address to prove you're legit.

What happens if I don't set up my MX records correctly?

If your MX records are wrong, emails sent to your domain won't reach Google's servers. This means you'll miss important messages! It's like having a mailbox with the wrong address – the mail carrier can't deliver anything. This can also cause problems with sending emails from your domain, as other email systems might not trust messages coming from you.

How long does it take for MX record changes to start working?

After you update your MX records, it can take a little while for the changes to spread across the internet. This process is called 'DNS propagation,' and it usually takes anywhere from a few minutes to 48 hours, but often it's much faster, like an hour or two. During this time, email delivery might be a bit mixed up.

Can I use just one MX record, or do I need all five for Google Workspace?

Google recommends using all five MX records they provide. These records have different 'priority' numbers. The main one is tried first, but if it's busy or having issues, the other records act as backups. Using all of them makes sure your email delivery is reliable, even if one server is temporarily unavailable.

What's the difference between the 'Host' field and the 'Value' when setting up MX records?

The 'Host' or 'Name' field usually tells the system *which* part of your domain the record applies to. For your main domain (like 'yourcompany.com'), you'll often use '@' or leave it blank. The 'Value' or 'Points to' field is where you put the actual Google server address (like 'ASPMX.L.GOOGLE.COM'). It's important to get these right so the record applies to your domain and points to the correct Google server.