To query the TXT record for DMARC, you can use:
dig TXT _dmarc.example.org
To query for a particular record for DKIM, you would need to know the selector prefix. You would then query it as TXT (for example with a google one):
dig TXT google._domainkey.example.org
From IETF RFC 4871 (emphasis added):
3.3.3. Key Sizes
Selecting appropriate key sizes is a trade-off between cost, performance, and risk. Since short RSA keys more easily succumb to off-line attacks, signers MUST use RSA keys of at least 1024 bits for long-lived keys. Verifiers MUST be able to validate signatures with keys ranging from 512 bits to ...
Your SPF record isn't affecting this.
By the looks of it, you have a DMARC record set up, and you are not signing outgoing mail with DKIM. To remedy the problem, either sign the outgoing mail, or remove the DMARC policy.
The DMARC record is a TXT record like the SPF record, but it is at _dmarc.example.net where example.net is your domain. If you don't ...
From the Domain-based Message Authentication, Reporting, and Conformance (DMARC) RFC section 11.4 (DMARC Tag Registry):
rua: Reporting URI(s) for aggregate data
ruf: Reporting URI(s) for failure data
Unless you enable reporting or use addresses matching the policy domain, neither rua nor ruf should do anything. See the RFC section 7.1 for details.
For DKIM records, if you have received a DKIM-signed email from that domain, look at the DKIM-Signature header line(s).
From the spec:
All DKIM keys are stored in a subdomain named _domainkey. Given a
DKIM-Signature field with a "d=" tag of example.com and an "s=" tag of
foo.bar, the DNS query will be for foo.bar._domainkey.example.com.
So in this ...
Providers send aggregate reports at varying times. Many come at midnight UTC, but some providers like Microsoft often send hourly reports. Forensic reports come in neartime, usually about 5-10 minutes after the failing message hit the ISP's front end inbound mailers.
You can tell RUA from RUF reports apart pretty easily. An aggregate, or RUA report ...
I have finally figured out why I was seeing these DMARC reports about properly signed email sent from my domain.
As I mentioned in the question, my DMARC record was "v=DMARC1; p=none; pct=100; sp=none; rua=mailto:email@example.com;"
By default, Google apps will not deliver emails sent to firstname.lastname@example.org to any of your mailboxes. In order for me ...
There does not appear to be a limit to the number of emails you can use in the dmarc rua attribute. However, the size limit of a TXT record in DNS is 255 characters, according to Max. Number of char in a TXT Record so the upper bound on number of emails is limited by that.
I successfully used four emails in my dmarc record, but a better practice is to use ...
Think of SPF and DKIM as ways to validate the mail path, and think of DMARC as an extension that also validates the message sender. Think of this as delivering a FedEx letter. It's easy to validate where the envelope was shipped from, and that the courier was legitimate, but it doesn't provide a way to prove that the letter inside the envelope is really ...
A few comments.
dmarc.org RUA comment
If you request that reports be sent to multiple URIs, the report sender can treat anything more than two recipients as optional. They are also allowed to set their own limit above two if they wish.
DNS TXT records are composed of a sequence of strings. "All printable ASCII characters are permitted in the attribute ...
As mentioned in the comments by @anx, hardly any mailbox hosting service ever sends forensic/failure reports anymore. And for good reason. There are several quality DMARC report visualization services out there that have blogged about the absence of and the reason why, for example: Dmarcian and Valimail.
The Dmarcian blog dates from late 2015, and back then ...
Your data is obfuscated which makes helping you difficult. I see a number of problems:
If you haven't obfuscated your IP address, your DNS passes rDNS validation but looks very much like a spambot. Try getting server.example.com setup as the PTR for your address and add server.example.com to your DNS. Getting the PTR record setup requires support of your ...
A solution to my problem is to have the SRS_EXCLUDE_DOMAINS setting of PostSRSD contain all the domains from which I send mail. I already tried this before, even before posting this question, but after having defined this setting PostSRSD would not start anymore, so I hoped there was a different solution. Apparently PostSRSD has a bug regarding this setting ...
As you can read here "....A selector is added to the domain name, used to find DKIM public key information...".
Also, in Wikipedia terms: "...The receiving SMTP server uses the domain name and the selector to perform a DNS lookup [...] the selector is a straightforward method to allow signers to add and remove keys whenever they wish..."
In other words, if ...
I did finally get this response from Google. I was glad to find someone who understood the issue, but unfortunately it looks like Google is sticking with their incorrect treatment of the DMARC directive.
Google Groups will only rewrite the From: header when the DMARC policy of the original sender (you in this case) is set to reject or quarantine.
If you do not protect a domain with SPF and DMARC other users on the Internet can use that domain for sending spam or phishing. This is true even if you do not send or receive email on that domain.
Even in the case where you only receive email on that domain, it is also recommended to set SPF and DMARC for the same reason.
OpenDKIM, OpenDMARC, Rspamd, ClamAV
I assume you have OpenDMARC configured to do SPF itself? You'll want to disable SPF/DKIM/DMARC checking in Rspamd then as well.
you need openDKIM before openDMARC so that the DMARC check can be done based on the Auth-Results: header set by openDKIM.
You want openDMARC before Rspamd so it can send DMARC reports on all ...
I ran some queries like spfquery --mfrom mail.mysteryscience.com -ip 2607:f8b0:4001:c05::232 on the results you provided. It appears you have not configured SPF for mail.mysteryscience.com to allow google to deliver email for that domain. That explains the SPF failures for deliveries from Google. The query above is based on the domains listed in the record....
Using Windows built-in tool nslookup
Open Command Prompt (cmd.exe)
Enter set type=txt
Enter _dmarc.somedomain.org, replace somedomain.org
Default Server: localdns
> set type=txt
_dmarc.somedomain.org text =
Under the basic assumptions underpinning DMARC, nobody should be able to pass either a DKIM or SPF test as your domain, unless the mail is coming from a server you control. A pass for either of the two is enough to confirm this.
Thus there is no way to force DMARC to require both pass, and there should be no reason to do so.
If third parties are able to ...
First of all, I don't know if there are any issues specific to how Gmail handles this.
Generally, however, while the DMARC spec does allow for reports to be sent to an external address, it also has additional validation steps for this scenario in order to limit abuse.
The report recipient domain should have a special record in place to indicate that it ...
At first: Exchange on premises does not support DKIM signing and verifying out of the box. Microsoft hasn´t added that yet and might also not do that. So you need a plugin.
But if you wish to go forward here, then Microsoft has a great tutorial here which explains how to setup DKIM on an on-premises Exchange environment.
In general the following steps are ...
I have figured it out. Not surprisingly, it was me misinterpreting the report, not Google getting their DMARC implementation wrong :)
The SPF result in the policy evaluated section that I was being confused by (copy posted in OP) is the DMARC evaluated SPF result after considering alignment.
This quote here explains the issue:
Please note that the SPF ...
SPF only specifies which addresses are authorized to send mail for your domain. It is up to the recipient to decide what to do with that information.
DMARC allows you to indicate exactly what actions you would like recipients to take when the SPF check fails.
These are not redundant, but complementary.
DMARC is how you define validation, disposition and reporting policies for your domain, and of more interest to you here, for messages that fail to pass SPF and DKIM (the two of them together).
Between DMARC, SPF and DKIM, it's DMARC that checks if the From: domain matches the any of the domains that passed SPF or DKIM. If there's no match, then the DMARC ...
If your domain does not have DKIM set, you definitely do not need DKIM set up. Its absence would not cause GMail to throw your e-mail to SPAM. Its presence might increase its SPAM rating so it would not be rejected.
To check your SPF, you need to tell us your domain and IP addresses of your SMTP server. Or, you can use online check tools on http://www....
sampled_out means that messages that were actually supposed to have your specified policy applied were exempted from this and instead got the next "better" policy applied instead. This based on that your DMARC record specifies that only a certain percentage should have the policy applied (this option exists to allow slow rollouts).
Ie, it seems that those ...
Unfortunately, it's a well-known fact that DMARC and some mailing lists are effectively incompatible.
The same problems originally stemmed from SPF itself, and have prompted mailing lists (as well as forwarding services) to implement a feature known as SRS (Sender Rewriting Scheme), which is a feature that must be implemented by the mailing list operators.