How to Set Up DMARC for Google Workspace

To set up DMARC for Google Workspace, publish one SPF record containing include:_spf.google.com, generate a 2048-bit DKIM key in the Admin console, publish it as a TXT record at google._domainkey and click Start authentication. Then publish a DMARC record at p=none, review the reports, align every other sender and progress to reject in stages.

Why the defaults are not enough

Google Workspace delivers mail reliably out of the box, which lulls many administrators into thinking authentication is handled. It is only partly handled. If you have not set up DKIM for your own domain, Google signs your outbound mail with a Google-owned default domain. That signature passes DKIM, but it does not align with your From domain, so it does nothing for DMARC.

That leaves SPF as the only route to a DMARC pass, and SPF alignment is the weaker of the two: it depends on the envelope sender (the Return-Path) matching your domain, and it breaks whenever a message is forwarded by a server that is not in your SPF record. If that distinction is unfamiliar, our article on DMARC alignment walks through it with examples.

A correct Google Workspace setup therefore has three parts, done in this order:

1. An accurate SPF record that includes Google.
2. A DKIM key for each sending domain, generated in the Admin console and switched on.
3. A DMARC record that starts in monitoring and progresses to enforcement on evidence.

Before you begin, run your domain through the DMARC checker to capture what is already published. It is common to find an SPF record left behind by a previous host or an old DMARC record pointing reports to an address nobody reads.

Step 1: the SPF record

Google’s sending servers are covered by a single include:

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

Publish this as a TXT record at the root of yourcompany.co.za. If an SPF record already exists, add the include to it rather than creating a second record, because two SPF records produce a permanent error that causes SPF to fail outright.

Keep an eye on the lookup budget. SPF allows a maximum of 10 DNS lookups during evaluation and a maximum of 2 void lookups (lookups that return nothing). Google’s include consumes several of the 10 through its own nested records. Add a newsletter platform, a helpdesk, an accounting package and an old hosting a mechanism, and many domains quietly exceed the limit. When that happens, receivers return a permerror and SPF stops contributing to DMARC at all.

Clean-up rules of thumb:

• Remove includes for services you no longer use.
• Remove a and mx mechanisms unless those hosts genuinely send mail as you.
• Prefer DKIM-based alignment for third-party services, which costs no SPF lookups.

Step 2: generating DKIM and starting authentication

DKIM for Google Workspace is managed in the Admin console under Apps, Google Workspace, Gmail, then the Authenticate email setting. The process:

1. Select the domain. If you have secondary domains or domain aliases that send mail, each one needs its own key. They are chosen from a drop-down in the same screen.
2. Generate a new record. Choose a 2048-bit key, which is the stronger and recommended option. Leave the selector prefix as the default google unless you have a specific reason to change it, which produces a host of google._domainkey.
3. Publish the TXT record. Google shows a value beginning v=DKIM1; k=rsa; p= followed by a long public key. Copy it exactly into a TXT record at google._domainkey.yourcompany.co.za.
4. Wait for DNS. Propagation can take from minutes to a day or more, depending on your DNS provider.
5. Click Start authentication. This is the step most often missed. Until you click it, Google does not sign with your new key, even though the DNS record is published.

When the DNS panel will not accept the key

A 2048-bit public key is longer than the 255-character limit for a single string inside a TXT record. Good DNS providers handle this automatically by splitting the value into multiple quoted strings. Some older control panels truncate or reject it. If that happens, either enter the value as separate quoted strings if your panel supports it, or move DNS to a provider that handles long records properly. Generating a 1024-bit key is a fallback for panels that cannot cope, but it should be treated as a temporary compromise.

Verifying it works

Send a message to an external mailbox, open the original headers and check the Authentication-Results line. You want dkim=pass with header.d=yourcompany.co.za. If the domain shown is a Google default domain, authentication has not been started for that domain.

Step 3: the DMARC record

Publish a TXT record at _dmarc.yourcompany.co.za:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.co.za

Use an address that can absorb daily XML attachments from many receivers, ideally a reporting service rather than a staff inbox. If the address sits on a different domain from the one being reported on, the receiving domain must publish an authorisation record, otherwise reports will not be sent.

Think about subdomains at the same time. A subdomain such as news.yourcompany.co.za inherits the policy of the main domain unless you set an sp tag or publish a separate DMARC record for it. That is usually what you want, but if a marketing platform sends from a subdomain that is not yet authenticated, tightening the main policy will affect it too. List every subdomain that sends before you move beyond monitoring, and leave out the ruf tag for forensic reports: few receivers send them, and those that do may include message content you would rather not collect.

Google’s own sender rules are relevant here. Since February 2024, Google and Yahoo have required senders of more than 5,000 messages a day to their users to have SPF, DKIM and a DMARC record in place. Even if your volume is far lower, the direction is clear: authenticated, aligned mail is the baseline. Our article on Google, Yahoo and Microsoft sender requirements covers the detail.

Routing pitfalls that quietly break alignment

Google Workspace is flexible about how mail enters and leaves the platform, and that flexibility is where alignment problems hide.

None of these is visible from the Admin console. They show up in aggregate reports as source IPs that pass or fail. Reading those correctly is covered in how to read a DMARC report.

Step 4: a staged rollout to p=reject

Once Google traffic is passing with aligned DKIM, follow a disciplined sequence:

1. Observe for at least one full business cycle, including month-end and any quarterly sends.
2. Remediate every legitimate sender that fails, by enabling custom DKIM or a custom return-path with the vendor, or by moving that sender to a subdomain with its own records.
3. Quarantine: change to p=quarantine, optionally starting with a lower pct, and monitor for missing mail.
4. Reject: change to p=reject early in the week, with a written approval and the previous record kept for rollback.
5. Watch: keep reading reports, because every new tool the business adopts is a potential new sender.

The reasoning behind each gate is in our policy rollout guide.

Google Workspace readiness checklist

• One SPF record including _spf.google.com, within 10 lookups.
• DKIM generated, published and started for the primary domain and every sending secondary domain.
• Test messages showing dkim=pass for your own domain, not a Google default.
• Gateways, relays and external SMTP routes accounted for in the reports.
• Unused domains locked down with v=spf1 -all and p=reject.

How MailMarq helps

MailMarq takes Google Workspace domains through this whole process without asking for any admin or mailbox passwords. We give you the exact records (or apply them where we manage your DNS), interpret the reports, work through the third-party senders and recommend each policy step for your sign-off. Ask for a free assessment to see where your domain stands.

Frequently asked questions

MailMarq
MailMarq is a managed DMARC service run from Johannesburg. Our team has built and managed business websites, hosting and email infrastructure for South African companies since 2016, and writes these guides from work on real domains.