Are we possibility having a reputation problems with Yahoo emails?
Yahoo raw mail header finds my policy I published:
Emails to clients at Google and Outlook are not ending up in spam, but Yahoo is.
Finally a week back we solved the dkim 'FAIL' with domain we were experiencing for a good long time.
This is a copy of the latest xml dmarc report from Yahoo:
<?xml version="1.0"?> <feedback> <report_metadata> <org_name>Yahoo! Inc.</org_name> <email>[email protected]</email> <report_id>1596849225.380362</report_id> <date_range> <begin>1596758400</begin> <end>1596844799</end> </date_range> </report_metadata> <policy_published> <domain>filmfix.com</domain> <adkim>r</adkim> <aspf>r</aspf> <p>reject</p> <pct>100</pct> </policy_published> <record> <row> <source_ip>126.96.36.199</source_ip> <count>2</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>pass</spf> </policy_evaluated> </row> <identifiers> <header_from>filmfix.com</header_from> </identifiers> <auth_results> <dkim> <domain>filmfix.com</domain> <result>pass</result> </dkim> <spf> <domain>filmfix.com</domain> <result>pass</result> </spf> </auth_results> </record> </feedback>
It looks like we are all good to go.
So I tested by sending an email, and my emails ended up in my Yahoo spam folder.
I must mention that my
text/plain raw block under
Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
still has some formatting issues. It has lots of
=3D20 and other strings inside it. Making it hard to read, like in here:
=3DEF=3DBB=3DBF =3D0D =3DE2=3D9D=3DA4 =3DC3=3D84pfel fallen von B=3DC3=3DA4= ume wenn sie =3D =3DC3=3DBCberreif =3D20 sind, oder wenn der Wurm im Apfel steckt. =3D0D =3D0A=3D
(It is work in progress for now.)
I since changed my dmarc DNS record from
v=DMARC1; p=reject; ... to
v=DMARC1; p=none; ... and will see if that could be the reason why they sometimes do not even get delivered; not even in spam!
and now I am back to:
v=DMARC1; p=quarantine; ...
Today we received an estimate inquiry request from a bellsouth.net email. He did not receive our automated estimate email reply.
We found this fact out by sending him a separate email, without any links in it, yet still using FilmFix.com, but that email ended up in his spam folder.
Response received from 188.8.131.52: Authoritative response (AA): No Recursion available (RA): Yes Truncated (TC): No Answer section: A-record for bellsouth.net: IP address: 184.108.40.206 TTL = 10800 (3 hours) Additional section: EDNS0 options: UDP payload size: 1280 DNSSEC OK (DO flag): No
looking up IP 220.127.116.11.in-addr.arpa I get this:
Response received from 18.104.22.168: Authoritative response (AA): No Recursion available (RA): Yes Truncated (TC): No Header: RCODE 3 - Non-Existent Domain Authority section: SOA-record for 77.216.in-addr.arpa: Primary DNS server: ns0.attdns.net Responsible person: [email protected] Serial number: 2019121901 Refresh interval: 3600 Retry interval: 1800 Expire interval: 2592000 Default / minimum TTL: 300 TTL = 300 (5 minutes) Additional section: EDNS0 options: UDP payload size: 1280 DNSSEC OK (DO flag): No
We also used to have AT&T as ISP, also providing us with a rDNS entry at the time (for a different IP address.)
Here are my DNS settings (a partial outtake.) I use Simple DNS Plus as controller.
I just noticed that there is an entry for 76-80-54-219.filmfix.net with a lower priority number of  (marked in blue), whereas 76-80-54-218.filmfix.net has . I only have spf, dkim and dmarc setup for IP 22.214.171.124, so I went ahead and removed that 76-80-54-219.filmfix.net entry. I am not sure if that could have been causing an issue. Gmail and Outlook have been OK with that configuration.
Some time back, well before spf, dkim and dmarc it was suggested to have two IP's to not end up in spam. I am not sure if this is still so.
I have been monitoring my dmarc reports. I use easydmarc.com to read them. here is my report from August 31, 2020 to September 14, 2020, also here as image:
On Sep. 2nd Yahoo! Inc. recorded a dkim fail, and on Sep 7th a dkim pass (but without notation of the dkim result.) It looks like we are still having issues with Yahoo.
In the report, it looks like we have had two impersonation attempts. One by secureserver.net 126.96.36.199, and another by hostpoint.ch 188.8.131.52, if I am reading this correctly.
Further more, I since added an image-tracker to my "requesting-an-estimate" auto reply emails. Like this I can identify if a user is getting the email they requested.
Request from email addresses from these domains
logged the image as requested.
These did not return a request for the image, from which I can conclude (with some assumption) that the email got never viewed (and probably ended up in spam):
I am now gradually moving towards dmarc reject policy for failed emails.
This is new policy
v=DMARC1; p=reject; pct=25; rua=mailto:[left out]; ruf=mailto:[left out]; sp=reject; fo=0:1:d:s;