It’s time to decode another deliverability definition. PSL stands for the Public Suffix List, and it’s one of those things that a certain subset of email geeks (and maybe web developer geeks) find very valuable.
What does it do? DMARC.org explains: “It [is a list that] was created to help browsers make decisions about which HTTP cookies a given website could create or read. Imagine if a bad actor could register a specially named new domain and read the authentication cookies in your browser that let you access your bank or social media accounts. Since then the PSL has found many other uses, one of the more critical being in determining when a request to issue a TLS certificate is too broad – with such a certificate, a bad actor could convince your browser that you’ve connected to your bank or social media site, when you have really connected to their scam site.”
And in the realm of email, the PSL is invaluable in that it helps email systems determine the organizational domain -- the topmost level of your domain name -- so that domain-level DMARC policy can be appropriately applied at that level and to subdomains below. This is easy to do in your head (mostly) when you’re thinking of “.com,” but there are a zillion other top level domains (TLDs) out there, and not all of them have the same policies when it comes to at what level a new domain is registered. And some have some ambiguity in domain registration policy, where a domain could be registered as example.com.country or as example.country. How do you determine which is which? By referencing the PSL.
Check the public suffix list for the largest suffix contained in the domain. For the .com, .edu, and many other popular TLDs, the suffix is just the TLD itself.
Keep one label past the public suffix and discard the rest.
A few folks will tell you that the PSL sucks; some folks may have a valid point about people hardcoding/caching old versions of the PSL in various tools or services, but often, it boils down to the PSL being the “least bad way” to identify things like organizational domain and certificate/cookie boundaries.
It’s time to decode another deliverability definition. PSL stands for the Public Suffix List, and it’s one of those things that a certain subset of email geeks (and maybe web developer geeks) find very valuable.
What does it do? DMARC.org explains: “It [is a list that] was created to help browsers make decisions about which HTTP cookies a given website could create or read. Imagine if a bad actor could register a specially named new domain and read the authentication cookies in your browser that let you access your bank or social media accounts. Since then the PSL has found many other uses, one of the more critical being in determining when a request to issue a TLS certificate is too broad – with such a certificate, a bad actor could convince your browser that you’ve connected to your bank or social media site, when you have really connected to their scam site.”
And in the realm of email, the PSL is invaluable in that it helps email systems determine the organizational domain -- the topmost level of your domain name -- so that domain-level DMARC policy can be appropriately applied at that level and to subdomains below. This is easy to do in your head (mostly) when you’re thinking of “.com,” but there are a zillion other top level domains (TLDs) out there, and not all of them have the same policies when it comes to at what level a new domain is registered. And some have some ambiguity in domain registration policy, where a domain could be registered as example.com.country or as example.country. How do you determine which is which? By referencing the PSL.
Here’s how DMARC handles that, as described on the Valimail blog:
- Take the domain from the 'From' address.
- Check the public suffix list for the largest suffix contained in the domain. For the .com, .edu, and many other popular TLDs, the suffix is just the TLD itself.
- Keep one label past the public suffix and discard the rest.
The PSL was originally created by the Mozilla Foundation, first published in March 2007.A few folks will tell you that the PSL sucks; some folks may have a valid point about people hardcoding/caching old versions of the PSL in various tools or services, but often, it boils down to the PSL being the “least bad way” to identify things like organizational domain and certificate/cookie boundaries.
Learn more about the Public Suffix List from Wikipedia.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.