According to this question, uRPF is running in strict mode because packets are dropped even when that route exists in the routing table. Maybe packets are dropped because the receiving interface is different from the interface the local router uses to send packets to that destination.
The ip verify unicast source reachable-via rx command enables Unicast RPF in strict mode.
To enable loose mode, administrators can use the any option (ip verify unicast source reachable-via any). In loose mode, it doesn't matter if we use this interface to reach the source or not.

The allow-default option allows the use of the default
route in the source verification process.

A DHCP server that receives a DHCPDISCOVER message may respond with a DHCPOFFER message on UDP port 68 (BootP client).
...
In the event that the DHCP server is not on the local subnet, the DHCP server will send the DHCPOFFER, as a unicast packet, on UDP port 67, back to the DHCP/BootPRelay Agent from which the DHCPDISCOVER came.

https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and management/dnacenter/tech_notes/b_dnac_sda_lan_automation_deployment.html

From the output we can see there are 2 NHRP Peers. The first one with the NBMA Address of
172.18.16.2 and the "Attribute" (Attrb) of Static (S) so we can deduce it is the Hub device.
Therefore the second one must be the remaining Spoke device with the attribute of Dynamic (D).

--> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==
Interface: Tunnel1, IPv4 NHRP Details
Type:Spoke, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 44.44.44.4 192.168.100.254 UP 00:03:40 S
1 12.12.12.2 192.168.100.2 UP 00:03:20 D