I pulled up a DMARC Analyzer report showing emails received on behalf of my domain:

DMARC report

In addition to my normal authorized (SPF+DKIM aligned) personal emails from the protonmail.ch domain, there are unauthorized emails coming from the google.com domain. I don't use any Google email services with this domain, and never have. My domain's DMARC policy is correctly rejecting these unauthorized emails.

I know the emails are truly originating from Google and not just random internet noise, because the emails are signed cryptographically by google.com.

(Rein has pointed out that they are actually signed by my domain, just forwarded by Google.)

Here is a snippet from a DMARC aggregate report (from Google) that shows two emails coming from one of Google's IPs:

      <source_ip>(IP address owned by Google LLC)</source_ip>

My SPF/DKIM/DMARC records are:

maxlaumeister.com: TXT "v=spf1 include:_spf.protonmail.ch mx -all"
protonmail._domainkey.maxlaumeister.com: TXT "v=DKIM1; k=rsa; p=(long key)"
_dmarc.maxlaumeister.com: TXT "v=DMARC1; p=reject; rua=mailto:(redacted)@rep.dmarcanalyzer.com,mailto:(redacted)@maxlaumeister.com; ruf=mailto:(redacted)@for.dmarcanalyzer.com,mailto:(redacted)@maxlaumeister.com; fo=1;

My question is: Why is google.com trying to send emails on behalf of my domain in the first place? And could this cause any deliverability problems for my legitimate emails?

2 Answers 2


Short Answer: You're seeing internally routed emails in your DMARC reports, for recipient domains hosted on Google GSuite.

From the screenshot you share, it seems like these emails sent from Google servers are actually allowed through, based on DKIM signing for your domain (100% DMARC compliance), while failing SPF alignment with your domain. Not visible from your screenshot, but I suspect Google has rewritten the return-path for the email to its own domain. You should be able to find that information in the actual XML files of the Aggregate reports.

Basically, these are forwarded emails. If you send emails to a Distribution List that is hosted in Google's GSuite (Groups for Business), those emails actually get forwarded to the final recipients, usually mailboxes in the same organization as the Distribution List. On an Office 365 Distribution List this type of routing would not appear in your DMARC reports, however, Google is very noisy about this and includes these forwards in their Aggregate Reports that are sent to the domain owner of the sending domain.

  • Thank you for taking the time to write this out. My understanding is that emails are not DMARC compliant unless SPF and DKIM both align (so if an email fails SPF it would automatically fail DMARC). I took a look in my aggregate report and couldn't find anything about return-path, but I did post a snippet of my aggregate report in the question. Finally, in light of that info about distribution lists, do you know if this setup could be causing any issue with deliverability of my legitimate emails to Google users? Commented Dec 20, 2018 at 18:35
  • DMARC is not looking for a FAIL but for a PASS. Either through SPF or DKIM. Regarding the Return-Path, that's the domain mentioned in the <SPF> node. Depending on the reporting organization, it could also be present as envelope_from in the <identifiers> node. Passing DMARC and DKIM, but failing SPF because of a routing mechanism internal to Google does not cause negative impact on deliverability, is my experience.
    – Reinto
    Commented Dec 20, 2018 at 19:46
  • Thanks for the explanation. I read up on DMARC and I think I understand better how this all works. I am planning to mark your answer accepted because this seems like a likely reason, but I want to wait and see if anyone has an external source that describes this behavior regarding Google's distribution list and DMARC reports (if it's ever happened to anyone else on the internet). Commented Dec 21, 2018 at 0:07
  • 1
    I guess it is hard to prove that it was a Distribution Group that forwarded the message. But, looking at the data, we can confidently say that: a) the original email was sent by you because the DKIM signature on your domain was in tact, b) the reported email was sent from a Google server / IP address, and c) the recipient mailbox is hosted on Google, since the report was generated by Google, as you mentioned.I do agree, it would be wonderful to have an actual statement by Google on this behaviour, although I did test the Groups for Business setup in GSuite in a free test tenant.
    – Reinto
    Commented Dec 21, 2018 at 13:18

Did you accept or reject a Google calendar invite? The creator of the event will get an email from Google using your email address as 'from' address.

Might be the case for other services offered by Google.

  • Thank you for the answer. Maybe other Google services are sending emails "from" me when I share files with others. Are there any sources official or otherwise that document any of this behavior? Commented Dec 17, 2018 at 6:28
  • Sorry I only found out about this two weeks ago, and did not have the time to look into it. Ido think it's strange for google to do something like this, as they seem to be pretty strict themselves when applying SPF/DKIM
    – Pit
    Commented Dec 17, 2018 at 6:35
  • I have experienced something similar. An invitation to a Google Calendar was sent "from" [email protected] but it actually was sent by a Google mail server since a Google Calendar mechanism was used. It should fail both SPF and DKIM in that situation and a DMARC policy of "reject" tells the receiving mail server to reject it. In my situation the recipient was actually a Gmail user, and Google sent the rejection response email "Message blocked. Your message to [email protected] has been blocked.... 550 5.7.1 Unauthenticated email from domain.com is not accepted due to domain's DMARC policy."
    – mikato
    Commented May 15, 2019 at 20:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.