May be they should test their DNS servers using:
https://www.dns-oarc.net/oarc/services/replysizetest
or setup edns udp size to 1400 instead of the default 4096 is they don't
want to allow fragmented packets in:
http://www.zytrax.com/books/dns/ch7/hkpng.html#edns-udp-size
This is also likely to a
> On Jun 7, 2016, at 10:31 AM, Simon wrote:
>
> Am 07.06.2016 um 18:27 schrieb Steve Atkins:
>> The 2048 bit key plus the CNAME gives a reply packet big enough that
>> the UDP reply to a non-edns query is truncated. Retrying over TCP
>> works, but a DNS resolver that doesn't do TCP would just er
Am 07.06.2016 um 18:27 schrieb Steve Atkins:
> The 2048 bit key plus the CNAME gives a reply packet big enough that
> the UDP reply to a non-edns query is truncated. Retrying over TCP
> works, but a DNS resolver that doesn't do TCP would just error out.
> That's probably why the DKIM temperror. If
> On Jun 7, 2016, at 9:06 AM, Simon wrote:
>
> Hello List,
>
> For quite some time I am noticing DKIM temperrors in DMARC reports
> (exclusively) from Microsoft. Until today I wasn't able to track down
> whatever is causing this:
>
> If a DKIM selector is a CNAME pointing to a 1024 bit key it
Hello List,
For quite some time I am noticing DKIM temperrors in DMARC reports
(exclusively) from Microsoft. Until today I wasn't able to track down
whatever is causing this:
If a DKIM selector is a CNAME pointing to a 1024 bit key it returns a
DKIM "pass". But if the selector points to a 2048 bi