Damn Spaces

Today on "Things I learned", I find out spaces, when they want to, will 'eff up your DNS records.

How do I know this. I had a potential client come in and ask why their email platform kept reporting to them that their DMARC wasn't set up. 

Oooo, I know how to start this one (or so I thought)...

  1. Ask for a test message
  2. Proceed to check headers (as I'm using a Workspace, it's a super fast check-a-roo in the Authentication-Results: header)
  3. Double-check result against a couple online tools
Everything looked peachy on the surface. DNS tools were showing it as correct and passing. Gmail was reporting that it was passing.

But it still wasn't being sensed.

Well, maybe it's a UI bug...

Send a test to aboutmy.email. If that comes back as passing, it's gotta be the UI.

Oh dang, aboutmy.email is saying it fails DMARC too. NOTE: I should have scrolled down at this point to see the details of the report, but I didn't have the results, my potential client on the other side of the screen did.

Something is off, but I can't see it in the online tools nor does it look off in the DNS being shown to me. 

Let's mess with the DMARC record a bit just to see. Disclaimer: don't mess with the DNS. I'm being a little silly with my word choice for fun. In reality, we just made an update.

Perhaps these tests are marking it as failed because the verbiage in both mentions having v=, p=, and rua=, but the record only has v= and p=. Doesn't feel like a good enough answer, but what the hell, let's go with it for now and run another test this time with an RUA.

So in goes an RUA record.

WOW, UI is sensing the DMARC record and it's passing in aboutmy.email.

Ok, this still makes no sense because I know aboutmy.email knows rua is not required.

So off I go asking questions.

And here is where I find out spaces be damned!

After a bit of back-and-forth, low and behold there was a space at the START of the DMARC record. The online tools weren't showing it because starting spaces in HTML be hidden. I didn't even CONSIDER how HTML could influence the output of a result - yet another learning from this one exercise caused by damn spaces. 

When this was run with dig or even host via the terminal, that space is a slap in the face...assuming you're wearing glasses to see it.

_dmarc.clientdomain.org. 13366 IN TXT " v=DMARC1; p=none;"

See it? Right there, before the 'v'.

Spaces in the front of the DMARC record prevented it from being sensed (not by everyone, but by enough to flag it as incorrect.)

And that right there is another thing I learned. One result is not enough, do it in MANY forms, especially if there is a problem that is fine on the surface, but you just know something is off. 

And pay attention to the details! I think that is my biggest 'damn it, I should have looked closer' moments here.

So what about the rua thing? Well the rua didn't do anything. The fix was updating the DMARC record. Somehow that mysterious space was in there, but was not visible in the UI (likely HTML having it's way with it) and by making an update to the record, that space was removed. We likely could have made a simple change to a semi-colon and had the same result (removing the space.)

And spaces (or the lack thereof) can plague you anywhere you go! Al Iverson, over at SpamResource, shares his story about how a missing space caused a spam filter to go haywire.

DAMN SPACES

Comments

Popular posts from this blog

WELCOME TO ISKTBN!

DNS: It's Damn Hard

DAMN Redirects