Receivers stop evaluating at ten lookups and return a permanent error. In practice your SPF is being ignored, so mail from some of your senders is already failing authentication even though the record looks correct.
Before you publish: This replaces include:mailgun.org with the addresses they resolve to right now, bringing you to 9 lookups. Flattened records are a snapshot. If any of these providers changes its sending IPs, your mail from that provider starts failing SPF with no warning. Re-check monthly, or keep the include and reduce lookups another way. At 793 bytes this exceeds the 255-byte DNS character-string limit and must be published as 4 quoted strings. Most providers do this for you; some require you to enter the quotes yourself. 793 bytes is a large TXT response and may fall back to TCP on some resolvers. Prefer removing an unused sender over flattening further. 2 redundant address ranges were removed because a broader range in the same record already covers them. No sender lost coverage.
Warning
3 DKIM keys are shorter than 2048 bits
google (1024-bit), k1 (1024-bit), mandrill (1024-bit). 1024-bit RSA is still accepted everywhere but is no longer considered strong, and some receivers have begun downgrading it. Rotation is handled by your provider, not by editing DNS directly.
What to do
Ask the provider behind Google Workspace, Mailchimp / Mandrill, Mandrill to reissue at 2048 bits.
Publish the new key on a fresh selector, then remove the old one once mail is signing with it.
Note
No MTA-STS policy
Mail sent to you can be downgraded to an unencrypted connection by an attacker on the network. MTA-STS closes that hole. Optional, but it is what separates a well-run mail domain from an average one.
Publish this TXT record at_mta-sts.lyft.com
v=STSv1; id=20260731000000
Before you publish: The record alone does nothing — you must also serve a policy file at https://mta-sts.lyft.com/.well-known/mta-sts.txt listing your MX hosts. Start with mode: testing, and only move to enforce once reports confirm nothing is failing.
Note
No TLS reporting
TLS-RPT asks other mail providers to tell you when encrypted delivery to your domain fails. It is the feedback loop that makes MTA-STS safe to enforce — without it you are switching on enforcement blind.
Publish this TXT record at_smtp._tls.lyft.com
v=TLSRPTv1; rua=mailto:tlsrpt@lyft.com
Before you publish: The mailbox must exist. Reports arrive daily as JSON attachments.
Note
Your domain qualifies for BIMI
lyft.com enforces DMARC, which is the hard prerequisite for BIMI — displaying your logo beside your messages in supporting inboxes. Adding it is now mostly a matter of hosting an SVG, plus a Verified Mark Certificate if you want Gmail to honour it.
Note
DNSSEC is not enabled
lyft.com is unsigned, so an attacker able to tamper with DNS responses could forge your SPF, DKIM and DMARC records — undermining all three. Most registrars and DNS hosts enable it with one click.
What to do
Enable DNSSEC in your DNS provider (Cloudflare: DNS → Settings → Enable DNSSEC).
Copy the DS record it generates into your registrar. Some registrars do this automatically.
Good
DMARC is at p=reject
The strongest policy. Mail failing authentication is rejected outright.