Receiving hundreds of Delivery Failure emails - how to report these Options

[bwawsc]

If you include the SMTP servers you want to use in your domain's SPF policy, then those servers are "permitted" (the downside to that being that you are also permitting anyone else who uses that SMTP server to send from your domain as well). This can get cumbersome, if you have many users and they all send from a variety of SMTP servers. In those cases, you might want to provide them with an authenticating SMTP server to use, independent of their ISP connection of the moment.

There are methods for forwarding services to use - but of course, they have to use them. If they are SPF-illiterate, they will cause problems.

The biggest problem seems to be learning (as a domain owner) how to construct a "proper" SPF policy. Many domain owners have no idea what SMTP servers their mail might be sent from, and get no help from their domain hosting service. It took me weeks and considerable persistence to get the information (only one host, not one of my MX servers - a very simple case). The second-biggest problem is learning how to publish the SPF record you have composed (most people have no direct access to their zone file, no idea where their authoritative name server is, and no idea how/who to contact about it).

Big companies should have no problem with any of this - but even so, it can be difficult to educate the network group about the needs of the email group. My company still hasn't published an SPF policy after months of badgering from within.

[StevenUnderwood]

Some suppliers still do not allow the TXT entries to be entered or modified which is required for SPF and is one of the major complaints against SPF in that it is taking over what is in the DNS definition an optional field, and giving it a specific purpose.

Prior to my leaving in the spring, I asked the provider for my previous employer and they stated they had heard several requests for it but had no plans to change their policy.

[bwawsc]

The RFC (4408) defines a new resource record Type SPF (code 99) but allows the publication of the SPF Policy in a TXT record for backward compatibility with early implementations. Unfortunately, many DNS management tool implementations do not yet support publication of code 99 (Type SPF) records, and some email receiver packages that support "SPF" do not check for code 99 records, only TXT. I don't think it is intended to "take over" TXT - it can still be used for many other purposes. It's just a convenient way to get SPF policies published without waiting for DNS server implementations to support a new Resource Record Type.

[StevenUnderwood]

The RFC (4408) defines a new resource record Type SPF (code 99) but allows the publication of the SPF Policy in a TXT record for backward compatibility with early implementations. Unfortunately, many DNS management tool implementations do not yet support publication of code 99 (Type SPF) records, and some email receiver packages that support "SPF" do not check for code 99 records, only TXT. I don't think it is intended to "take over" TXT - it can still be used for many other purposes. It's just a convenient way to get SPF policies published without waiting for DNS server implementations to support a new Resource Record Type.

http://www.ietf.org/rfc/rfc4408.txt

IESG Note

The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408)
are published simultaneously as Experimental RFCs, although there is
no general technical consensus and efforts to reconcile the two
approaches have failed. As such, these documents have not received
full IETF review and are published "AS-IS" to document the different
approaches as they were considered in the MARID working group.