* No comments. It is difficult to add a comment. In particular, we want to be able to list which ticket requested each item in the SPF setting so that history is retained.
* Ugly diffs. If you add an element to the SPF setting, the diff will show the entire line changed, which is difficult to read.
* Too many lookups. The SPF RFC says that SPF settings should not require more than 10 DNS lookups. If we manually flatten (i.e. "inline") an include, we have to remember to check back to see if the settings have changed. Humans are not good at that kind of thing.
* Comments can appear next to the element they refer to.
* Diffs will be shorter and more specific; therefore easier to read.
* Automatic flattening. We can specify which includes should be flattened and dnscontrol will do the work. It will even warn us if the includes change.
## Syntax
When you want to specify SPF settings for a domain, use the
overflow: "_spf%d", // Delete this line if you don't want big strings split.
raw: "_rawspf", // Delete this line if the default is sufficient.
parts: [
"v=spf1",
// fill in your SPF items here
"~all"
],
flatten: [
// fill in any domains to inline.
]
}),
...
...
);
```
The parameters are:
*`label:` The label of the first TXT record. (Optional. Default: `"@"`)
*`overflow:` If set, SPF strings longer than 255 chars will be split into multiple TXT records. The value of this setting determines the template for what the additional labels will be named. If not set, no splitting will occur and dnscontrol may generate TXT strings that are too long.
*`raw:` The label of the unaltered SPF settings. (Optional. Default: `"_rawspf"`)
*`parts:` The individual parts of the SPF settings.
*`flatten:` Which includes should be inlined. For safety purposes the flattening is done on an opt-in basis. If `"*"` is listed, all includes will be flattened... this might create more problems than is solves due to length limitations.
`SPR_BUILDER()` returns multiple `TXT()` records:
*`TXT("@", "v=spf1 .... ~all")`
* This is the optimized configuration.
*`TXT("_spf1", "...")`
* If the optimizer needs to split a long string across multiple TXT records, the additional TXT records will have labels `_spf1`, `_spf2`, `_spf3`, etc.
*`TXT("_rawspf", "v=spf1 .... ~all")`
* This is the unaltered SPF configuration. This is purely for debugging purposes and is not used by any email or anti-spam system. It is only generated if flattening is requested.
We recommend first using this without any flattening. Make sure
`dnscontrol preview` works as expected. Once that is done, add the
flattening required to reduce the number of lookups to 10 or less.
To count the number of lookups, you can use our interactive SPF
debugger at [https://stackexchange.github.io/dnscontrol/flattener/index.html](https://stackexchange.github.io/dnscontrol/flattener/index.html)
## Notes about the DNS Cache
dnscontrol keeps a cache of the DNS lookups performed during
optimization. The cache is maintained so that the optimizer does
not produce different results depending on the ups and downs of
other people's DNS servers. This makes it possible to do `dnscontrol
push` even if your or third-party DNS servers are down.
The DNS cache is kept in a file called `spfcache.json`. If it needs
to be updated, the proper data will be written to a file called
`spfcache.updated.json` and instructions such as the ones below
will be output telling you exactly what to do:
```
$ dnscontrol preview
1 Validation errors:
WARNING: 2 spf record lookups are out of date with cache (_spf.google.com,_netblocks3.google.com).
Wrote changes to spfcache.updated.json. Please rename and commit:
$ mv spfcache.updated.json spfcache.json
$ git commit spfcache.json
```
In this case, you are being asked to replace `spfcache.json` with
the newly generated data in `spfcache.updated.json`.
Needing to do this kind of update is considered a validation error
and will block `dnscontrol push` from running.
Note: The instructions are hardcoded strings. The filenames will
not change.
Note: The instructions assume you use git. If you use something
else, please do the appropriate equivalent command.
## Caveats:
1. Dnscontrol 'gives up' if it sees SPF records it can't understand.
This includes: syntax errors, features that our spflib doesn't know
about, overly complex SPF settings, and anything else that we we
didn't feel like implementing.
2. The TXT record that is generated may exceed DNS limits. dnscontrol
will not generate a single TXT record that exceeds DNS limits, but
it ignores the fact that there may be other TXT records on the same
label. For example, suppose it generates a TXT record on the bare
domain (stackoverflow.com) that is 250 bytes long. That's fine and
doesn't require a continuation record. However if there is another
TXT record (not an SPF record, perhaps a TXT record used to verify
domain ownership), the total packet size of all the TXT records
could exceed 512 bytes, and will require EDNS or a TCP request.
3. Dnscontrol does not warn if the number of lookups exceeds 10.
