Defaults.Exposed

Why gappssmtp.com is signing your mail

You opened the raw headers on a message you sent from your own domain and found a DKIM signature from example-com.20230601.gappssmtp.com. Google Workspace is signing your mail with a key Google owns, under a hostname Google owns, because example.com has no DKIM key of its own in DNS. Every message you send passes authentication at the far end today. You are still not finished, and the gap shows itself the day you try to tighten DMARC, or the day a customer forwards your invoice.

The header line, read left to right

This is the signature Gmail attaches when a Workspace domain has never had its own key set up. The message was sent by [email protected].

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=example-com.20230601.gappssmtp.com; s=20230601;
        h=from:to:subject:date:message-id:mime-version;
        bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=;
        b=kQ3tR7Lp...

The d= tag is the signing domain and the s= tag is the selector. A receiver joins the two, fetches the TXT record at 20230601._domainkey.example-com.20230601.gappssmtp.com, and checks the signature against the public key it finds there. That record sits in Google’s zone. Your dots became dashes so your domain could be folded into a hostname under gappssmtp.com, and the date is the generation of Google’s shared signing key. The DKIM guide covers the remaining tags if you want the full grammar.

The receiver’s verdict, in a Gmail inbox, looks like this:

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=20230601 header.b=kQ3tR7Lp;
       spf=pass (google.com: domain of [email protected] designates 209.85.220.41 as permitted sender) [email protected];
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

All three lines say pass, though the dkim line isn’t helping you at all.

Why a passing signature can still count for nothing

DMARC wants a DKIM signature that verifies and belongs to the domain in the From header. Under the relaxed alignment every Workspace domain gets by default, the organisational domain of d= has to match the organisational domain of header.from. example-com.20230601.gappssmtp.com reduces to gappssmtp.com, and gappssmtp.com is not example.com.

So the dmarc=pass above came from SPF alone: the envelope sender was [email protected], the connecting IP belonged to Google, and example.com’s SPF record includes _spf.google.com.

SPF has a known weakness, and it is forwarding. When a customer’s mailbox forwards your quote on to their personal account, or a mailing list resends it, the message arrives from a server your SPF record has never heard of. Here is the same message after one hop through a forwarder that does not rewrite the envelope sender:

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=20230601 header.b=kQ3tR7Lp;
       spf=softfail (google.com: domain of transitioning [email protected] does not designate 203.0.113.9 as permitted sender) [email protected];
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com

The DKIM signature survived the hop, because a signature travels with the message and an honest forwarder leaves it intact. A signature under example.com would have carried DMARC through on its own. A signature under gappssmtp.com cannot, whatever its verdict, because it never aligned in the first place.

You are on p=none, so the failure costs nothing yet. Once you move to p=quarantine, your forwarded messages start landing in spam, even though the signature on them verified fine.

One domain, walked through

Take example.com as it stands on the morning you notice the header. Its DNS holds four lines that matter here.

example.com.                    MX   1 smtp.google.com.
example.com.                    TXT  "v=spf1 include:_spf.google.com ~all"
_dmarc.example.com.             TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"
google._domainkey.example.com.  TXT  (no record)

Mail is hosted at Google. SPF authorises Google’s servers. DMARC is published in monitoring mode with a reporting address. The fourth line explains the header: nobody ever put a key at google._domainkey, so Google falls back to its own.

The aggregate reports arriving at [email protected] have been saying this for weeks, in a format almost nobody opens. Inside the XML, the record for the forwarded messages reads:

<record>
  <row>
    <source_ip>203.0.113.9</source_ip>
    <count>3</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example-com.20230601.gappssmtp.com</domain>
      <selector>20230601</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>example.com</domain>
      <result>softfail</result>
    </spf>
  </auth_results>
</record>

Read the two dkim elements against each other. Under auth_results the signature passed. Under policy_evaluated it failed. auth_results records the cryptography, policy_evaluated records alignment, and DMARC only counts alignment.

Even the messages that went straight to their recipient carry the mark. Their rows show spf pass and dkim fail under policy_evaluated, with disposition none because your policy asks for nothing. The report has been saying, on each message since the domain was set up, that one of your two legs was missing the whole time.

Publishing the key Google is waiting to make

In the Admin console, open Apps, then Google Workspace, then Gmail, then Authenticate email. Pick example.com from the domain selector and click Generate new record. Leave the key length at 2048 bits unless your DNS host cannot store a value that long, and leave the selector prefix as google. The console shows you a hostname and a TXT value:

Host name:  google._domainkey
TXT value:  v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxq7c...

Create that TXT record at your DNS host. Two things tend to go wrong here. One is the host field. Some DNS panels want google._domainkey and add example.com themselves; others want the full google._domainkey.example.com. Type the full form into a panel that appends the zone and you have published the key at google._domainkey.example.com.example.com, where no receiver will ever look. The other is the value. A 2048-bit key is longer than a single 255-character DNS string, so some panels need it pasted as two quoted strings and some split it for you. Paste it whole, save, and check what the zone is serving before you touch the console again:

$ dig +short TXT google._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxq7c..." "...IDAQAB"

Two strings in the answer are fine; resolvers join them. An empty answer means the record has not propagated yet or it sits at the wrong host. Wait until you see the key, then go back to Authenticate email and click Start authentication. Google’s servers can take a while to see a new record, and the console refuses to start until they do, so do not keep pressing the button.

Once authentication has started, keep the record alive. If a zone migration drops it, or a panel rewrites the host, Google carries on signing as example.com against a key nobody can fetch, and receivers report:

dkim=temperror (no key for signature) [email protected] header.s=google

That’s worse than the gappssmtp default you started with, because now the aligned leg fails outright where before receivers ignored it.

Checking the new signature

Send a message from [email protected] to a Gmail address you control and open Show original. The signature block now reads:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=example.com; s=google;
        h=from:to:subject:date:message-id:mime-version;
        bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=;
        b=Zw8mN2xU...
Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=google header.b=Zw8mN2xU;
       spf=pass (google.com: domain of [email protected] designates 209.85.220.41 as permitted sender) [email protected];
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

The d= tag is your domain, header.i= is your domain, and the dmarc=pass now has two aligned results behind it instead of one. Forward that test message through a personal mailbox and look again: spf softfails as before, dkim still passes on example.com, and dmarc passes on the strength of the signature, which it couldn’t do before.

Within a few days the aggregate reports change shape too. The dkim element under auth_results names example.com with selector google, and policy_evaluated shows dkim pass on every message Google sent. Any row that still names the gappssmtp domain is a sender the console did not cover: a second Workspace domain you never repeated the steps for, or mail that went out during the propagation window.

The scan reads the same DNS your recipients read and reports whether a key is published at the selector your provider uses. If some other system sends as you and you cannot tell which selector it signs with, the selector guide shows how to read it out of any message it has sent.

What the census can and cannot see here

Google Workspace answers the MX for 21,565,780 of the 173,425,856 domains with a mail exchanger among the 316,600,902 graded in the September 2026 census. It’s an adoption count: the number of domain owners with this exact console page in front of them.

The census probes a fixed set of selectors under each domain, google among them, and on the 75,823,110 domains where the DKIM check ran it found a key at one of them on 37,999,462 (50.1%). A domain on the gappssmtp default adds nothing to that count, because its key lives under Google’s zone rather than its own. From the outside, which is where every receiver stands, a domain signing as gappssmtp.com looks the same as a domain with no DKIM at all.

Then tighten DMARC

With an aligned signature on every message Google sends, read the next two weeks of reports and look for any source that still fails both legs. Those are either systems sending as example.com that you haven’t authenticated yet (the invoicing tool, say, or the website contact form), or they’re somebody else using your name. Authenticate the first kind at their own consoles. The second kind is what the reject policy below is meant to block.

When the reports show nothing legitimate failing, change one token:

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

and, after another reporting cycle, p=reject. The DMARC guide covers the pct and sp tags if you want to stage it. The gappssmtp fix is what makes this step possible. On a borrowed signature, p=reject would have thrown away your own forwarded mail, so you would have stayed on p=none for good and called it done.

Create the TXT record today. It’s one DNS value, and once it propagates Google signs as d=example.com.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.